Wed, 24 Nov 2004
Monotone
There's been some talk about arch and other VC systems lately. I'm not really too interested in going over all the details via a blog entry; we should probably set up a version-control-flame-fest mailing list or panel at some conference for that sort of thing. But, I did want to put in a few good words for monotone.
monotone is very friendly for "off-line" use, by which I mean there's actually no such thing as "on-line" use as there is with cvs. You keep the subset of history that you want in a local database, and all the ordinary user commands interact with this. You can sync this database with other databases; I would suggest ordinarily just doing this automatically via cron. Ordinarily it is simplest to just keep all of history around.
A consequence of this approach is that you can commit at any time. If two commits are made against the same base revision, a micro-branch is made that you must then merge. This has some nice properties. For instance, if someone sends you a patch against some release of your package, you can just check out that release -- no matter how long ago that was -- apply the patch directly, and then use the normal monotone merge commands to merge the results with other changes.
Since monotone has all the other nice properties of the current generation of free VC systems (atomic commits, cheap branches), and since there is no enforced central server, it is trivial to do things like have experimental branches, private branches for unfinished patches, and the like.
You can do one better than that, though. With monotone you aren't required to accept any particular person's changes, you can choose keys to trust and keys not to trust. The way this would work is that core maintainers would be generally trusted (you could have a re-signing robot to automate this if you cared). Other people could commit patches more or less freely, they just wouldn't show up until a core maintainer approved them. So, this would be a nice supporting piece for the typical project, where non-core maintainers submit patches for approval; it would eliminate the need to actually apply such patches.
The other feature worthy of note, and the reason for monotone's name, is its support for testing. Monotone lets you attach some metadata to a revision (using the normal signing process); then you can use this metadata to change how "update" works. So, you can have an automated tester sign revisions that are known to work, and then only update to known-working versions. For GCC, you could have multiple such testers, with different acceptance criteria (works on x86 native, works for ppc cross, etc).
posted at: 19:18 | path: /software | permanent link to this entry
