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

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

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


From: Miles Bader
Subject: [Gnu-arch-users] Re: Design proposal to kill pristine trees
Date: 09 Oct 2003 10:37:34 +0900

Tom Lord <address@hidden> writes:
> Well, if you have a hook whose job is to add a needed revision lib to
> _some_ revlib on the path, that hook can make sure to add one to the 
> revlib in the right place (even if it's already available on the
> "wrong" device).
> 
> If you want to use hard-link hacks, it's quite obvious that such hacks
> should search the revlib path for a copy on the right device.
> 
> I don't think you want "a hook that replaces (or returns) a revlib
> path".

What I probably really want is `local' revlibs.  Having a hook that
returns a revlib path allows me to do this without getting into big
arguments over what the right algorithm is.

> I think you want a hook that notices demand for a locally cached copy,
> and hard-link algorithms that are sensative to devices.

Perhaps adding enough hacks in _other_ hooks might address the
hard-linkability issue (though I'm not convinced of that yet), but none
of the above address the `manageability' issue -- global resources get
to be a pain beyond a certain point.  It's like the comment about
pristines being nice under {arch} because they go away when you remove
the tree; I want something a little different, but for similar reasons.

I'd like to keep things localized in some way; it doesn't necessarily
have to be exactly the way I described.  I don't _want_ to have a
gigantic long global path (containing many rarely-used entries) if I can
avoid doing so; if it comes down to it, I'll put up with it, but it's
not because I think such a solution is a good one, only because I don't
like arguing about it.

-Miles
-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson




reply via email to

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