Martin Pool's blog

Mail me RSS Bazaar distcc Canonical is hiring! flickr

An amalgam of distributed version control

I've been hanging out with some of the GNU Arch hackers. I had started out trying to describe what GNU Arch ought to take from other systems — primarily simplicity in both model and interface. There are some good ideas in Arch, but also a lot of what is technically known as "crack". [*This somewhat offensive term seems to have acquired the meaning in GNOME of "unnecessary user-hostile complexity".] I have ended up thinking that Arch is not the right foundation for this.

A huge amount of good thinking has gone into various distributed systems over the last few years. I don't personally find any of them totally satisfying, but I think trying to pick the best ideas from each into a new codebase may work well.

There may be some code in a while.

The high points:

• Simple things should be simple (remember this single file locally); complex things should be possible. At the low end I would like to be as simple as RCS; at the high end as powerful (or nearly as powerful) as the existing systems.
• Version control systems have several purposes: collaboration, branching, undo of mistakes, backup, tracking down bugs by looking at history, distribution, etc. Experimental systems (e.g. Darcs) may choose to ignore some, but I think a "serious" system cannot.
• The history by which a patch arrives at its eventual destination is interesting; this history includes who merged the patch, what they did, and what trees it passed through. Only Arch, as far as I know, keeps track of this.
• The Arch interface is too complex. This complexity is not merely in the user interface but rather saturates the model. It is not desirable to use wrappers to hide underlying complexity. It must be removed by radical surgery; fortunately I think no one will miss it.
• Allowing anonymous read-only access by just putting files on a web site is very nice for both usability and security.
• Cryptographically signing revisions/changesets is also good, and falls fairly naturally out of deciding that history should be append-only. Signing should be done by GPG (unlike Monotone) — open source developers have already built up signed keys and we should use them.
• Unless there is a good reason to do otherwise, the interface should be familiar to users of CVS and Subversion: add, diff, commit, ignore, etc should work as expected.
• There are two basic complex merge problems: cherry-picking changes, and history-sensitive merging within an arbitrary graph. I don't think any single existing system (open or closed) can do both correctly, but I think it is possible.
• History should be strictly and reliably recorded. I want confidence the system can reproduce my tree's state at any point in the past. At the same time people want exemptions when for example accidentally committing confidential information.

More later. I have a lot more documentation and the start of some code. I have shown a mockup to both Arch developers and Arch haters and both sets liked it.

Havoc has posted a list of desired features. I think my design can address most or all of them, some in quite entertaining ways. Some of the more workflow-related requirements I think I would keep out of the core tool.

Other comments from Tom and Colin.

posted Thu 2 Dec 2004 in /software/vc | link

Copyright (C) 1999-2007 Martin Pool.