[Top][All Lists]

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

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

From: Martin Pool
Subject: [Gnu-arch-users] Re: Why we might use subversion instead of arch.
Date: Thu, 04 Mar 2004 16:16:23 +1100
User-agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity. (Debian GNU/Linux))

On Fri, 27 Feb 2004 18:41:43 +0000, John Goerzen wrote:

>> 2.6.0 tree hard linked to the library and with a few changes 
> 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.

It's an option which is off by default; you need to be sure that your
editor will handle it correctly before you turn it on.  However, it
can make such an enormous difference to performance that it is worth
getting it working.  It turns out that almost all tools do the right

Even before arch, I used to regularly use 'cp -al' to make link farms
of the kernel source before patching.  This makes diffing very fast
and saves disk space.  Arch gives you a safer, more automatic way to
do this.

>> So I am quite happy with tla but nevertheless admit that I 
>> have no idea on how Subversion behaves with this same tree 
>> in terms of storage requirements and operation time. Do you 
>> have any concrete values?
> 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.

Subversion cannot make hard links between the pristine (svn-base) and
editable files.  When I asked a few months ago, I found out this was a
design problem, not just a matter of programming.

The other big advantage is that libraries let you have a single
pristine file linked into many trees.  If you want a hundred kernel
trees checked out with slightly different patches applied, tla will do
that as efficiently as 'cp -al'.  Subversion would require 2 * 100 *
200MB, which is starting to get a bit large.

My observation is that tla (~1.2) uses less disk but more CPU than
Subversion.  On the other hand, Subversion used to be very slow indeed
before they made a big drive for performance.

When I do little things on the kernel right now, I use quilt and 'cp
-al'.  tla and subversion are both too slow for what they buy me.
(But if I was doing large changes or working with other people using
arch maybe it would be different.)

Incidentally, Quilt looks a lot like somebody tried to write a very
simple arch in 60 minutes.  If you want to get tla adopted by core
kernel hackers, it might help to do a 'quilt -> arch' guide.  Maybe I


reply via email to

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