My sympathies are currently with arch for the following reasons:
- The backend is standard UNIX tools, patch, diff and tar and your file system. No Database!
- Has distributed repositories. That looks really nice, as a central repository, that may not be available at all times, can be a pain in the ass.
- Author appears to know, what he's doing: Read this criticism of the development of Subversion. I think some of the observations are good like these two:
Well, that's the problem with some design patterns like attaching property lists to everything under the sun: they don't really solve design problems but they give you an operational language in which to _restate_ design problems.
The problems are: (1) unless you have at least one fully worked design for how to implement your API, you shouldn't have any confidence that good implementations can exist; (2) unless you have at least two fully worked designs for how to implement your API, and they make usefully contrary trade-offs, you should really start to wonder whether doing extra work to make an abstraction here is the right way to proceed.
- Single file commits, without committing the whole tree are considered a "special" case. I don't want to adapt my developing style to the tool. (See also: Software Adjuvant)
- May or may not cope well with whitespace in filenames.
- Possibly too slow with Mac OS X, though I don't know what a revision library is yet:
Accessing hardlinks on HFS+ is approximately an order of magnitude slower than accessing regular files. This has fairly serious performance implications if you plan on using a revision library with tla.
- Rebuttal to above criticism :) Not quite as clever though.
- Small user base. No nifty GUI tools like TortoiseCVS.
- Didn't see offhand any support for $Id$ and $Log$ for in-source expansion
- Doesn't work well on WIN32.
- Data is stored in gzipped tars. Not exactly the most failsafe format.