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

[Andrea Arcangeli]

On Fri, Oct 03, 2003 at 05:38:48PM +0100, Bruce Stephens wrote:
> Andrea Arcangeli <address@hidden> writes:
> 
> > On Fri, Oct 03, 2003 at 01:52:11PM +0100, Bruce Stephens wrote:
> >> Pau Aliagas <address@hidden> writes:
> >> 
> >> [...]
> >> 
> >> > But (and that's a big but), I don't see any danger in hardlinking
> >> > pristine trees. The danger is the same than if you corrupt a local
> >> > pristine, be it hardlinked or not, but the benefits are obvious:
> >> > space saving, full speed gets, etc. Pristine trees are neeed, for
> >> > instance, to compute what-changed.
> >> 
> >> [...]
> >> 
> >> > Does anybody have an opinion about it?
> >> 
> >> Much better to have sparse revision libraries, and do away with
> >> pristine trees altogether, IMHO.
> >
> > Do I understand correctly the pristine tree is a temporary thing needed
> > just to diff against it?
> 
> I don't think it's temporary.  You get one (unless you say otherwise
> with the relatively new --no-pristine flag) whenever you get a working
> tree, and it lives in the {arch} directory (so if you've got ten
> working trees for the same revision, then you'll have (by default) 10
> pristine trees).  It gets updated when you do replay, update, commit
> so it corresponds with whatever the working tree corresponds to.  
> 
> If you try doing a diff (using what-changed, for example) against a
> revision for which there's no revision library, and no pristine tree,
> then I think you get an error message saying that you don't have an
> appropriate pristine tree, but I don't think arch will create one
> automatically.

I see, I didn't look much into the contents of {arch} yet (except the
slowdown during commit due the number of patches increasing).

so the assumption that you can do everything you want as far as you
don't execute 'tla commit' would go away. "everything you want" could
corrupt the revlib.

So I guess we shouldn't take risks and we shouldn't alter the behaviour
unless the user asks for it in his ~/.arch-params. If you ask for
hardlinks in ~/.arch-params, then *everything* (obviously pristine trees
too), should be generated with hardlinks. Otherwise nothing should be
generated with hardlinks.

get -l can stay but probably it's not needed anymore after we have the
~/.arch-params people using hardlinks will use it everywhere, people not
using hardlinks will never use it. it's an user choice. I wouldn't make
special cases between workdir and pristine trees, I would hardlink
either everything or nothing.

> > If the pristine tree is not temporary then I don't see the
> > difference between revlibs and pristine trees.
> 
> That's the point, I think.  There is a difference, which is that until
> Pau did the work on making revision libraries sparse, revision
> libraries had to contain all revisions, whereas pristine trees only
> need to contain one (occasionally more than one, but not that often).

I see. However the problem is that you couldn't checkout out of pristine
trees if they're inside {arch} ;) So it's a bit different still. The
pristine tree goes away when the workdir is deleted, but I want to
retain the 1 revlib afterwards anyways.

and with the full hardlink behaviour really having the pristine tree and
the working dir in the fs won't take up much more space than the rev lib
alone (that's one of the features).

> But (once Tom takes Pau's changes) revision libraries are close to
> becoming a practical alternative to pristine trees.  The only catch is
> that we'll probably need some way to automatically do library-add when
> a desired revision isn't there, and many people will want some means
> of automatically trimming the revision library to remove unused
> revisions.

there's still a difference IMHO, that is I don't want library-add to be
executed automatically ;). I prefer to choose 1 single rev lib to keep
cached even after I delete the working dir. The pristine tree is still
more a "temporary thing" that goes with the working dir. It's not
deleted automatically but I can easily get rid of it, and I'll do it
much more frequently than I do with the cached rev lib.

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/