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).