* aegis
must be setuid root.
no network model (changesets can be isolated and shipped around via email or http if you want), otherwise use NFS (!).
* darcs
Oh look, it’s written in Haskell.
NEXT!
* dcvs
It’s a shellscript frontend to CVSup, written in modula-3, that wrappers the existing CVS repository structure.
NEXT!
* arch
Repository format is braindead: Changeset is a log file plus a tarball of all new files and patches; you can create a “cached” revision where it builds the canonical representation of a particular version to avoid having to open 500 tarballs back to root. Repositories regularly grow too large and you have to create new ones (you can base a branch in one repository off a branch in another, so this more or less works). The docs suggest anually. You know, RCS fixed this problem two decades ago?
network API is SFTP; a corrupt client (think, hacked user machine) can blow away the repository itself.
At least it’s not still written in shell.
* meta-CVS
Wrapper around a CVS repository, works on the client side only. Only adds a few features (file type handling, filename and directory versioning, yawn).
* monotone
From the manual, section 2.0.2:
Many commands require you to supply 40-character SHA1 values as arguments, which we refer to as versions.
NEXT!
* openCM
Version 0.1.2alpha7pl2.
NEXT!
* Subversion
Subversions problems are well documented elsewhere, but briefly: You don’t get full functionality without using apache2 as part of your server, it uses sleepycat db as the backend, which causes maintainance nightmares. And it’s just “a versioned filesystem” that happens to implement changesets on top of it. Ugh. Why did they bother using sleepycat db instead of just picking up the RCS file format, which already works just fine and has less baggage? Anyway, it doesn’t do anything really interesting besides atomic changesets, that CVS doesn’t already do.
* vesta
Configuration management AND build tool. Ugh. I do not want to adopt your workflow, thanks anyway.
