Martin Pool's blog

Mail me RSS Bazaar distcc Canonical is hiring! flickr

Arch vs Svn

Garrett points to Tom Lord's Diagnosing Svn article and Greg Hudson's response.

I think they are both basically correct. (It's always nice to see developers from competing projects be fair, honest and civil.)

I would like to write about this in more detail later. I think it's possible that it's possible there is no single right way to do version control. It's possible that for different projects Subversion, Arch, quilt, monotone, Aegis or something else might be the right choice. In particular Subversion benefits from being a relatively easy change from CVS.

berlios.de has a comparison of different SCM systems, but I don't really think their format addresses the problem: it is too much of a matrix of different features, whereas I think people really want to know what system suits their particular environment.

A draft:

System	Good at	Bad at
CVS	Trees which don't move around or branch very much. Everyone knows how to use it. Good tools: emacs, viewcvs. Predictable, though often predictably mediocre. The safe choice.	Many features missing: poor support for branching and merging. If you accidentally delete or move a tag, it's gone for good. Renames are changes/adds. Commands are unorthogonal and hard to script.
Subversion	A better CVS. Easy to learn from CVS. Good for centralized trees. Atomic commits make merges a bit easier. Supports Windows. Tags/branches are versioned. Safer handling of binary files.	No really intelligent merge tools. Berkeley DB backend can be flaky. Putting tags/branches into a single namespace gives the risk that people will check out a tree of every tag ever, which might be many gigabytes. Many annoying dump/reload transitions to handle database upgrades.
Arch	Proper changesets. Intelligent merge. Very clean internal design. Great for open source projects feeling a bit adventurous. Completely distributed: built-in support for mirroring, can work on laptop and sync up when reconnected. You can start your own branch from any tree without needing write access to the upstream tree. Archives can be published on any web or FTP server: no need for a special service like sourceforge, and less of a security risk. Support for maintaining a "library" containing hardlinked read-only views of different revisions.	Relatively hard to learn, because of many new concepts and only moderate documentation. Few support tools for browsing repositories. Poor support for Windows, and Windows-like situations such as spaces in filenames. No standard annotate/blame command. Enforces some unixy naming conventions (e.g. hello--mainline--0.1) — which might be a feature, but can be hard to take at first.
Quilt	Keeping track of a set of patches to a tree obtained from someone else. Making short stubby branches easy. Has the unique(?) feature of allowing work in a single tree at the same time on several layered but separate patches -- fix a typo separate from adding new code in the same file.	Keeping track of patches once you've written them. Managing a main tree, rather than a short branch.
Aegis(*)	Enforces process: commits must not break build and test. Distributed repositories. Good for in-house projects that strongly care about testing?	Must run as root. Hard to learn(?) Doesn't follow modern unix idioms(?)

(I haven't used Aegis; don't believe what I say.)

Please mail me with additions/corrections.

posted Fri 13 Feb 2004 in /software/vc | link

Copyright (C) 1999-2007 Martin Pool.