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

[Mikhael Goikhman]

On 04 Dec 2005 11:42:19 -0500, Stefan Monnier wrote:
> 
> > Disagree. Revision libraries although nice to have are not needed for
> > real work with tla. Pristines and periodical cacherevs are often enough.
> 
> Why settle with "often enough" when you can have revision-libraries?

Because revlib is a ridiculously expensive solution maybe?

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

Automatic revlib is a no-no. Revlib should be manually configured on a
filesystem that is 1) fast and capable, no nfs, 2) formatted for a huge
number of small nodes, 3) set with appropriate user quota.

> Yes the implementation of revlibs could be improved as well, but tla
> without revlibs is simply too painful to use in too many cases.

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.

If you work with a local archive or a local mirror, then again, revlibs
are not needed for the normal work.

> Now, that doesn't mean cacherevs are unnecessary.  The two are largely
> orthogonal.  But, yes, having a revlib does change the use of cacherevs.
> They make it possible to focus on having just at most one cacherev per
> version, covering the latest revision (or nearby).

I much more often want to work with a pristine revision in my tree than
the latest revision in archive, so all this is questionable for me.

A good (compact and fast) solution is to have a local archive mirror, and
cacherev every 25 or 50 revisions, depending on tree size. Then you don't
need to have unmaintainable revlib trees that make du/cp/rm work forever.

Regards,
Mikhael.