[Dev] Version control systems

[Greg Noel]

On Friday, Jul 23, 2004, at 12:28 US/Pacific, Morgen Sagen wrote:

> Since performance principle number 2 listed at 
> http://gnuarch.org/arch-tech.html is: "Disk space is cheap", one would 
> get the impression that Arch also is not shy about using lots of disk. 
> :-)

They have a similar attitude toward CPU time and memory; there's a 
distinction between "cheap" and "free" that they don't seem to get.  
Good design is a balance of tradeoffs; you can't just ignore them.  The 
GNU folks have a bad habit of not spending enough time on design and 
end up wasting all three (often at the same time) when a better design 
would be faster, smaller, and scale better.  (This is a bone I've 
picked with them in the past; don't get me started.)

> Since I haven't actually used Arch, I don't know how this pans out 
> during real day-to-day use.

Take this with a grain of salt, since I've never evaluated arch, but as 
I understand it, arch chews up space on the server side, not the client 
side.  It also uses forward deltas, so a number of operations are very 
expensive, to the point that it's recommended that archives be 
essentially recreated regularly, so that you end up with disconnected 
segments of development.  (It's also a lot less mature, so these are 
things that may be cured eventually.)

As for the client side, my understanding is that the simplest (and 
default) configuration keeps only one copy.  However, if you choose, 
you can create a distributed mirror and work against a local archive 
instead of a remote one, and have all the advantages of disconnected 
operation.  In other words, if you have the space, you can chose to 
spend storage to improve your own performance; it's not something 
forced on you.

> So far the chandler CVS module is around 11MB, so in the grand scheme 
> of things disk-space usage will probably rank low on the list of 
> deciding issues.

It's only 11Mb now, but by the time it grows to a stable size, it will 
add lots more icons, some larger pictures (think of a splash frame), 
hopefully lots of tests, and a whole bunch of code.  It's going to 
double, and double again.  If the eventual size is closer to 50Mb, 
"wasting" that much space for every client checkout is a _big_ chunk of 
disk.

I'm not saying this is a fatal impediment, but as you point out, it's 
good to have all the pros and cons.  It would affect me personally; I 
run PPC-based Linux machines (and some Macs) and I have the habit of 
tracking open-source projects and compiling them to make sure they run 
with my systems.  I have about 200Gb worth of sources currently and my 
disk bays are full.  If projects start converting to Subversion, I'm 
going to have to start dropping projects.

> ...  Actually, I just found this document from someone who has spent 
> some time looking at Subversion, Arch, and Monotone (somewhat): 
> http://www.dwheeler.com/essays/scm.html<smime.p7s>

An interesting document; thanks for bringing it to my attention.  It 
has some additional pros and cons that should be mined out, but it 
basically reinforces my personal assessment that Subversion doesn't add 
enough over CVS at this point and that arch is too young (and insecure) 
to be trusted for mission-critical use.  In another year or two, things 
will be different and it'll be worth reexamining.

-- Greg Noel, retired UNIX guru