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

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

Re: [Gnu-arch-users] Re: patch: automatic cacherev and smarter get


From: Mikhael Goikhman
Subject: Re: [Gnu-arch-users] Re: patch: automatic cacherev and smarter get
Date: Wed, 7 Dec 2005 22:20:53 +0000
User-agent: Mutt/1.4.2.1i

On 06 Dec 2005 23:13:27 -0500, Stefan Monnier wrote:
> 
> >> I really wish tla stopped supporting pristines and just forced the use of
> >> a greedy revlib (which would be setup automatically in a default location,
> >> if needed).
> 
> > This would be insane. You suggest that whenever someone requests a tree
> > of 1000 files, 10Mb, tla should create million of files occupying 10Gb.
> > [This is optimistic, since just nodes alone of typical 4Kb occupy 4Gb.]
> 
> Watch out: strawman argument!
> Where did I say "dense"?

The situation I described is likely to happen even with "sparse" revlibs,
just not immediately. It is very easy to get a tree with 1000 files in
any even small project (every new revision adds new files to {arch}).

You claim (quoted) that manual setup of such massive structure as revlib
is not needed and tla may perform it automatically. Strawman argument?

> > In almost no cases. If it is a commit-only tree, you need a pristine
> > only; if it is a replay-only tree with local changes, a pristine again.
> 
> The only real difference between a pristine and a revlib is that the
> pristine is not shared among checked out trees and can't be conveniently
> placed on a more efficient filesystem.

I may accept the first "not shared" argument although this is actually a
win in many situations, but not the second one. tla may expect that the
tree directory is the most efficient place, otherwise a user would choose
another filesystem to hack. For no-hacking trees there is --no-pristine.

Moreover, there are several obvious differences you didn't mention.
Relevancy (store only most needed revisions), locality (is moved/removed
together with the tree), high speed of creation (replay, no need to rm).

Regards,
Mikhael.




reply via email to

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