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

[Tom Lord]

    > 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).

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
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.

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
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
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.

-t