gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Miles Bader
Subject: Re: [Gnu-arch-users] designing how to kill pristine trees
Date: Fri, 3 Oct 2003 19:50:37 -0400
User-agent: Mutt/1.3.28i

On Sat, Oct 04, 2003 at 08:50:28AM +1000, Robert Collins wrote:
> > Maybe an automatic `subdirectory of the parent of the outermost
> > {arch}-containing dir' type thing, vaguely like tla's current
> > sibling-pristine hack?
> 
> Yuck. Just symlink ~/.arch-cache somewhere sensible.

That doesn't work at all -- I have multiple groups of source code, and I'd
like the pristine cache for each project tree to remain near the associated
source trees.

For something like this, the homedir is simply a poor location, and having
just one cache location is not suitable for everybody (perhaps it is for some
people).

E.g., some places I have source trees at work:

 Local disk:
   /usr/local/src/* -- the pristine trees should go somewhere in /usr/local,
                       preferably in /usr/local/src

 Small NFS-mounted disk:
   ~/src/*          -- homedir is OK for pristines, but I'd prefer something
                       nearer the actual source location, like
                       ~/src/++arch-cache

 Very large NFS-mounted disk:
   /proj/soft2/uclinux/src/*        -- pristines trees should go in this dir
   /proj/soft2/uclinux/uclinux/*    -- pristines trees should go in this dir
   ... many others of this type ...

The basic rule is that I want the caches to be near the source dirs, because
it makes them easier to manage:

  device-wise -- Sharing the disk with the actual source code means that
                 pristine trees will share any `properties' the project disk
                 has, such as size, location, etc.  It's also important for
                 me since I'm one of those nutcases that wants to hardlink my
                 pristine trees with my project trees.

  name-wise -- Being near the source means that I can _see_ them, which is
               important if there are lots of pristine trees, and makes it
               natural to operate on them in tandem with their associated
               source trees.  For instance if the uclinux project gets
               booted, and /proj/soft2/uclinux gets deleted, so do the
               associated pristine trees.

> Otherwise, some folk will end up with the cache at /.arch-cache.

Only if they store their source trees in /...

How did you come to that conclusion anyway?  My basic idea for an algorithm
is to search for the `outermost' {arch}-containing dir in the current
project tree, and put the cache in its parent.  This would result in the
cache being a `sibiling' of the projec tree.  I think for many people, this
would do the right thing.

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]