[Top][All Lists]
[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.
- Re: [Gnu-arch-users] Storage efficiency of revlibs, (continued)
- Re: [Gnu-arch-users] Storage efficiency of revlibs, Mikhael Goikhman, 2005/12/06
- [Gnu-arch-users] Re: Storage efficiency of revlibs, Stefan Monnier, 2005/12/06
- Re: [Gnu-arch-users] Storage efficiency of revlibs, Ludovic Courtès, 2005/12/07
- Re: [Gnu-arch-users] Storage efficiency of revlibs, Mikhael Goikhman, 2005/12/07
- Re: [Gnu-arch-users] Storage efficiency of revlibs, Ludovic Courtès, 2005/12/08
- Re: [Gnu-arch-users] Storage efficiency of revlibs, Mikhael Goikhman, 2005/12/09
- Re: [Gnu-arch-users] Storage efficiency of revlibs, Ludovic Courtès, 2005/12/12
- Re: [Gnu-arch-users] Storage efficiency of revlibs, Mikhael Goikhman, 2005/12/12
- Re: [Gnu-arch-users] Storage efficiency of revlibs, Ludovic Courtès, 2005/12/13
[Gnu-arch-users] Re: patch: automatic cacherev and smarter get, Stefan Monnier, 2005/12/06
- Re: [Gnu-arch-users] Re: patch: automatic cacherev and smarter get,
Mikhael Goikhman <=
- Re: [Gnu-arch-users] Re: patch: automatic cacherev and smarter get, Stefan Monnier, 2005/12/07
- [Gnu-arch-users] Re: patch: automatic cacherev and smarter get, Matthieu Moy, 2005/12/07
- Re: [Gnu-arch-users] Re: patch: automatic cacherev and smarter get, Mikhael Goikhman, 2005/12/07
- Re: [Gnu-arch-users] Re: patch: automatic cacherev and smarter get, Stephen J. Turnbull, 2005/12/07
- Re: [Gnu-arch-users] Re: patch: automatic cacherev and smarter get, Andy Tai, 2005/12/08
- Re: [Gnu-arch-users] Re: patch: automatic cacherev and smarter get, Stefan Monnier, 2005/12/08
- Re: [Gnu-arch-users] Re: patch: automatic cacherev and smarter get, Ludovic Courtès, 2005/12/09