Re: [Gnu-arch-users] hardlinked pristine trees

[Andrea Arcangeli]

On Fri, Oct 03, 2003 at 10:08:03AM -0700, Tom Lord wrote:
> 
> 
>     > From: Andrea Arcangeli <address@hidden>
> 
>     > Do I understand correctly the pristine tree is a temporary thing needed
>     > just to diff against it?
> 
> More or less.
> 
>     > I want only 1 revision lib. the revision lib is the cache, the pristine
>     > tree is not. I don't want more than 1 copy unpacked, and I don't need
>     > any cacherev. With just 1 revlib fairly near the head, I can diff
>     > against all previous revisions very efficiently by creating temporary
>     > pristine trees with hardlinks. Then those pristine trees can be deleted
>     > after the diff has been generated.
> 
>     > If the pristine tree is not temporary then I don't see the difference
>     > between revlibs and pristine trees.
> 
> The plan, such as it is, is to try to eliminate pristine trees, but
> some more hacking is needed before that can be done.
> 
> Revision libraries are currently optional -- pristine trees are
> currently (mostly) not optional.  Pristines act as a kind of
> "fallback" that provides needed functionality even if a revlib isn't
> present (or lacks the needed revision).

Makes lots of sense.

> The chief virtue (and also vice) of pristine trees is their location.
> They allocate space addressed in the same subtree as the project tree
> they help.   The virtuous aspect of that is that if you `rm -rf' a
> project tree, that has the side effect of freeing-up local revision
> cache space dedicated to that tree.   In short, revision-cache

Exactly. That was my point about claiming them more "temporary" than
revlibs. However we can't share them across multiple work dirs. I guess
that's the worst part of the story about pristine trees.

> space-management using pristines happens pretty much "for free"
> whereas using any other technique, space-management is going to
> require new code and new mechanisms.

yes. the revlib would grow.

> For example, consider what happens if you view a revlib as a cache.
> Suppose I `tla get' a revision that I'm not usually interested in --
> but want to to a little work on.  And suppose further that this adds
> some revisions to my revlib.  The problem arises then: how does the
> system know when those newly added revlib entries are no longer
> needed?  It's not an insoluable problem; it's not a conceptually

correct. If we're still stateless so it's insoluable. And that's why I also
find a value in still having pristine trees.

> difficult problem: it is a tricky problem to solve really well -- to
> solve in a way that works smoothly and that always feels like The
> Right Thing.  (In other words, there's no point in replying with some

yes, giving a state to the revlib is not a black or white thing.

> obvious generality like "make it an LRU cache" or anything comperable
> -- the hold up here is the _details_ of actual _implementation_.)
> 
> Changing the subject slightly:  You say you want exactly 1 revision
> lib.   Ok -- so do I.   On the other hand, in general, that isn't a
> satisfactory restriction.   Two reasons are:
> 
> 1) It's quite economic that, in a coding shop bound together by a LAN, 
>    I will want to NFS-mount a "master" revlib that is built and fully
>    populated for some set of revisions for the benefit of all members
>    of the shop.    At the same time, it is likely I'll want supplement
>    that with 1 or more personal revlibs for things not covered by the 
>    shared revlib.
> 
> 2) As hardlink hacks come on line, the absense of cross-device
>    hard-links has to be considered.   Again, this suggests that I will
>    want more than one revlib in some environments.

yes.

OTOH maybe what you really want is a replicated {revision} directory in
every different fs so you can still hardlink. Other environments are
different of course. It's all very personal I guess.

thanks,

Andrea - If you prefer relying on open source software, check these links:
            rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
            http://www.cobite.com/cvsps/