Re: [Gnu-arch-users] designing how to kill pristine trees

[Miles Bader]

On Fri, Oct 03, 2003 at 11:01:12AM -0700, Tom Lord wrote:
> A default path for the default local cache is fine.  ~/.arch-cache
> perhaps[1]?  It's not obvious to me that the cache should be the same
> thing as a revision library (even if they overlap in implementation)[2].

I can't really offer a better suggestion, but ~/.arch-cache would be
problematic in many environments I've worked in, because homedirs are often
(1) NFS mounted, which obvious sucks if you project tree is on a local disk,
and (2) potentially more spaced-bounded than other directories (for instance,
in an environment where you have giant raid disks for software development,
but everybody's homedirs are somewhere much less expansive).
Also, this would result in pristine dirs not being shared in the case where
multiple people used the same project tree (I'm thinking `occasional'
sharing, not everyday sharing, e.g., "Bob can you type this command...").

Maybe an automatic `subdirectory of the parent of the outermost
{arch}-containing dir' type thing, vaguely like tla's current
sibling-pristine hack?

For instance, if you have

   /usr/local/src/big-project/{arch}
   /usr/local/src/big-project/sub-project/{arch}

and  you do a pristine-needing operation in .../sub-project, it will default
to using

   /usr/local/src/++arch-cache

[Maybe having a `++' file in such a visible location will annoy people, but
it seems like a good idea not to _by default_ hide such a large
automatically-created directory.  tla could _search_ for both .arch-cache and
++arch-cache, but only _create_ ++arch-cache; then users who are annoyed by
it could just do `mv ++arch-cache .arch-cache'.]

It's just a heuristic, of course, but I think it has a few of advantages:

  * It's very likely that the cache will be on the same device as the files
    (you might not always want this of course; maybe you'd like your sources
    in NFS, but your cache on a local disk -- but that's probably a case for
    an explicit user option).

  * It's `close' to the sources, and by default visible.  This makes `where's
    all my disk space going???' problems a bit easier for the user to
    resolve, and I think in general makes sense when you have to manage lots
    of source trees.

-Miles
-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]