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

[Robin Farine]

John Goerzen wrote:

> Yes, for several reasons.  The machine in question is a 2U server with 5
> SCSI disks in RAID-5.  Adding 200GB of storage to it is neither cheap
> nor easy, and would mean downtime that is probably unacceptable.

In this case yes. I was thinking of a developer's rather 
cheap but powerful IDE-based private machine (like mine) 
where it makes sense to have an archive library for local use.

> Not to mention that 200GB is just a completely outlandish figure to ask
> someone to have for this sort of project.

Why? Given the price I don't see the outlandish aspect of 
it. Most of the disk space can be used as a non-backuped 
area where to store things like Arch revision libraries, 
debian apt-proxy mirrors, the last 3 seasons of *Trek in 
mpegs or whatever. Not a server with expensive scsi 
hardware, just a personal machine.

> 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 revision library that tla automatically updates when the 
need comes instead of creating pristine trees. It is also 
quite useful when one uses Perspective.

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

Yes that's what I mean. Since tla verifies the inode 
signatures of a library file before actually using it and 
refuses to proceed if the file has changed, it does not 
present an additional risk (the increased probability of 
bugs excepted, naturally).

Now I confess that from time to time I have to rebuild parts 
of my library e.g. because I forgot to rm before cp. That's 
not a big deal, and now 'tla changes' even lets us relink 
our working trees to the library.

> tla commit takes me on the order of minutes.  This on a dual 2GHz Xeon
> machine with 15000RPM SCSI drives.

You seem to be using tla-1.1 and explicit ids, I am using 
ReiserFS, tla-1.2, name ids and hard linked trees. This and 
a few resource leakage fixed since 1.1 might explain the 
difference in performance.

> Subversion takes up more space on-disk for this project than tla, but
> behaves far quicker.  I may have posted about it at some point; I
> originally tried this project with Subversion.  I seem to recall
> Subversion using about twice the amount of space as tla for its
> repository, though that advantage is probably being eaten up by the need
> to cache so frequently with tla these days -- tla replay is really slow,
> and tla update even more so.

Yeah, if you almost exclusively rely on a tla archive and 
its cached revisions then I almost feel how painful it could 
be. But hey, sorry for repeating myself :), having a big 
hard disk that allows one to keep a library full of 
revisions combined with the hard links trick really makes 
the difference.


Robin