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

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

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


From: Andrea Arcangeli
Subject: [Gnu-arch-users] Re: hardlinked pristine trees
Date: Fri, 3 Oct 2003 19:16:10 +0200
User-agent: Mutt/1.4.1i

On Fri, Oct 03, 2003 at 06:42:21PM +0200, Pau Aliagas wrote:
> On Fri, 3 Oct 2003, Andrea Arcangeli wrote:
> 
> > On Fri, Oct 03, 2003 at 01:52:11PM +0100, Bruce Stephens wrote:
> 
> > > Much better to have sparse revision libraries, and do away with
> > > pristine trees altogether, IMHO.
> 
> Please test sparse revision libraries, have a look at the shared inodes 
> and report any bugs. As it uses the well tested functions of libarch, it 
> should rock.
> 
> > Do I understand correctly the pristine tree is a temporary thing needed
> > just to diff against it?
> > 
> > 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.
> 
> Neither do I.
> 
> If Tom would enlighten me on how to do away without pristine trees, I'd do 
> my best to farewell them. It sounds better than losing time in hardlinking 
> them, if possible.

Oh, if the revlib already exists and we know it's identical to the
pristine tree that we want to generate, then we should definitely diff
against it instead of wasting time hardlinking. That would be a quick
check inside the revision libs directory.

However if this revlib doesn't exist, then I'm unsure if we should
create the revlib or to create the "more temporary" pristine tree
(inside the working dir).

The fact the revlibs don't grow while executing what-changed has a value
to me, it's claner to get rid of the working dir and to delete all the
pristine trees at the same time.

OTOH, if you have more than 1 workingdir diffing against the same
revision, the pristine tree would be duplicated I guess, while they
wouldn't be duplicated if they were revision libs instead.

So theoretically we could also destroy all the pristine trees and we
have a better chance at sharing the information with other working dirs,
but pristine trees still would have some value (in terms of being much
more 'temporary' than the revlibs and separated from them).

I'm fine either ways.

One other advantage of killing the pristine tree, is that then we
could hardlink it always, while we probably can not with the pristine
tree inside the workdir.

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/




reply via email to

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