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

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

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


From: Andrew Suffield
Subject: Re: [Gnu-arch-users] patch: automatic cacherev and smarter get
Date: Fri, 25 Nov 2005 18:57:06 +0000
User-agent: Mutt/1.5.11

On Wed, Nov 23, 2005 at 10:39:09PM +0000, Mikhael Goikhman wrote:
> > > It depends.  If you have 50 small patches that fix typos or so, then
> > > on a large tree this is wastefull.
> > 
> > Or even large changes that only touch half the files - the hardlinking
> > of revision libraries is *really* good most of the time, and cacherevs
> > have nothing similar.
> 
> This is only theoretically correct. In reality, cacherevs are compressed,
> so they are usually more disk friendly then a hard-linked revlib.

I find reality to be roughly the opposite of this.

> Besides, a revlib consumes a _huge_ amount of inodes that constitutes a
> real problem in many cases (compared to one tarball per 50 revisions).

git already proved this is not a real problem.

> > We had this thread years ago, and to summarise:
> > 
> >  - you want revision library entries for people doing any kind of real
> >    work with tla
> 
> Disagree. Revision libraries although nice to have are not needed for
> real work with tla. Pristines and periodical cacherevs are often enough.

Pristines are *horrible*. Cacherevs are too slow.

> >  - cacherevs are only really interesting to people who want to use
> >    'get'
> 
> Cacherevs are helpful with merges not less than with 'get'.

Only with those 'merges' that involve 'get' operations. I mostly merge
using replay, where they're no use at all.

> greedy revlibs on
> every developer account is quite expensive, while cacherevs are not.

True enough. Also, computers are expensive, while noodles are not.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

Attachment: signature.asc
Description: Digital signature


reply via email to

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