Re: [Gnu-arch-users] Re: Design proposal to kill pristine trees

[Miles Bader]

On Wed, Oct 08, 2003 at 04:14:46PM -0700, Tom Lord wrote:
> > > A fixed path for revision libraries is fine.  It should _not_ have a
> > > mechanism for invoking a script to compute the path.  Miles'
> > > requirements can be satisfied in cleaner ways.
> 
> > Which are?  As described so far, a fixed path is certainly _not_
> > sufficient.
> 
> Yes it is.   Please spare me from thread archaeology and explain again
> why you think otherwise.

Ok; I'll describe my particular environment, and how I'd like to have things
work.

[I use the term `working directory' below instead of `project tree'
because the latter sounded slightly confusing in some places :]

I have various working directories.  Conceivably many more than now (tla
isn't quite polished enough to use for everything I'd like to use it for).

These working directories are located both on many devices (some are on
local disk on my PC, some are on NFS servers), and namespace-wise, in
many disparate locations -- but they tend to occur in `groups', e.g., I
might have /foo/proj1/more-junk/src/package{1,...N} and
/bar/proj2/junk/path2/src/package{1,...N} (though many more than two
such `groups')

To optimally use revision libs/pristine-trees I'd like to have them (1) on
the same device as the working directories that use them, and (2) `near' the
working directories in the namespace:

   I want (1) because that makes hardlink hacks possible, and also because
   it ensures that the revlib shares various properties of the device like
   disk space (it simplifies management of things like diskspace if I can
   just move a whole subtree from one disk to another).  It also is
   obviously important in the case of an nfs filesystem -- the revlib
   should be visible to all those that need it.

   I want (2) because it makes it simpler to manage the revlibs --
   solutions like pristines-in-{arch} are hard to manage because things end
   up in too many places, and it's a pain to locate them all and treat them
   like a unit, but solutions like `put everything in one giant directory'
   is also a pain because it means there's _lots_ of stuff unrelated to
   what I'm worried about.  My most recent idea [*] was to have my script
   search upwards from the working directory for `.arch-pristines' and
   `.arch-revlibs' directories, which makes it fairly simple to locate the
   revlibs/pristines at an `appropriate' distance from the working dirs.

   Note that that as large-scale projects are `finished' (or abandoned :-),
   source trees become sort of `dormant' -- I don't want to have to think
   about them, but I'd like them to still _work_ if I go back and do
   something.

The main point is that I'd like some mapping from working-dir =>
revlib-path, which I'd use to achive the `locality' I want.  I'm also not
entirely sure that I know _what's_ best, which is one reason I like the
idea of a script -- though if tla directly implemented an algorithm like
[*] above, I'd probably be happy (but would other people?).

Conceivably, I could use a single static path containing a long list of
all my various revlibs located in different places.  However this seem
wrong for several reasons:

 (1) It would sometimes do the wrong thing -- what if I have working
     directories from the _same_ archive located on two different devices?
     I'd like the revlibs used to be the ones that are located `close' to
     the working dir, not those that are first on the path.  [This is not a
     theoretical example either, BTW, I do use the same logical sources in
     multiple places.]

 (2) It would be a pain to manage, especially given the presence of a many
     `semi obsolete' source dirs, which may occasionally change location.
     I'd like these to just continue working if I need them, but I don't
     want the management burden of keeping some global path updated for them.

So that's my state.

Thanks,

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'