Nat! bio photo


Senior Mull

Twitter Github Twitch

Lookin past CVS

I am debating with myself, if I want to use arch or Subversion.

My sympathies are currently with arch for the following reasons:

  1. The backend is standard UNIX tools, patch, diff and tar and your file system. No Database!
  2. 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.
  3. 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.

Things that make me suspicious about arch:

  1. 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)
  2. May or may not cope well with whitespace in filenames.
  3. 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.

  4. Rebuttal to above criticism :) Not quite as clever though.
  5. Small user base. No nifty GUI tools like TortoiseCVS.
  6. Didn't see offhand any support for $Id$ and $Log$ for in-source expansion
  7. Doesn't work well on WIN32.
  8. Data is stored in gzipped tars. Not exactly the most failsafe format.

Also quickly looked at monotone, which uses an embedded SQL database, which is not to my taste.