[Top][All Lists]

[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: Robin Farine
Subject: Re: [Gnu-arch-users] Re: Why we might use subversion instead of arch.
Date: Fri, 27 Feb 2004 21:12:18 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031221 Thunderbird/0.4

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

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.


reply via email to

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