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

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

Re: [Gnu-arch-users] Re: Why we might use subversion instead of arch.


From: Charles Duffy
Subject: Re: [Gnu-arch-users] Re: Why we might use subversion instead of arch.
Date: Fri, 27 Feb 2004 13:09:19 -0600

On Fri, 2004-02-27 at 12:41, John Goerzen wrote:
> Not to mention that 200GB is just a completely outlandish figure to ask
> someone to have for this sort of project.

He didn't say it would take 200GB, but that storage is cheap.

A revision library will almost certainly not be as expensive as you
expect -- though I'd strongly reccomend using a filesystem where there's
no maximum inode count and tail compression is available. (Yes, though I
never expected to do so, I'm reccomending use of ReiserFS).

> > I am using a greedy library. A 'tla changes' on a Linux 
> 
> What exactly is a "greedy library"?  I've seen terms like this floating
> around but can't seem to find anything in the docs or help text about
> it.

A greedy library is a revision library that adds new revisions to the
library on request.

A sparse library is a revision library that skips revisions which
haven't been explicitly added, for use by folks like yourself who are
conservative with their HD space.  Sparse libraries can be less
efficient than non-sparse libraries if additions to the library are done
in the wrong order, and IMHO aren't worth using in most cases (but then
IMHO, you're making much ado about nothing re revlib size).

> Are you saying that you hard link the checked-out tree -- the thing you
> obtain with "tla get" -- to the library?  That strikes me as very
> dangerous and error-prone.

You *can* do that; that's what "tla get --link" and "tla changes --link"
do. TLA checks the revision library for corruption and informs you that
you need to rebuild a revision should you corrupt one inadvertantly.

> > in it takes about 3s (with name ids). On a tree two thirds 
> > the size of the Linux kernel tree but with explicit ids, 
> > 'tla changes' takes about 4s.
> 
> tla commit takes me on the order of minutes.  This on a dual 2GHz Xeon
> machine with 15000RPM SCSI drives.

Because you're ignoring all the performance-enhancing features out of
some (best I can tell) untested belief that they'll take too much space.





reply via email to

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