arch
Feature ComparisonsHow does arch
stack up
against the competition?
Note: I don't intend to either slam or mis-represent CVS or Subversion. CVS is a proven work-horse with which a lot of useful work continues to be accomplished. Subversion is an interesting project. If there are errors in my characterization of CVS or Subversion in this feature comparison chart, please point them out so I can correct them.
product | atomic commits | file renames handled cleanly | advanced merging featues | easy development on branches | automatic ChangeLog generation | all revisions accessible as regular trees | distributed and private repositories | easy server administration | scalable | web browser |
---|---|---|---|---|---|---|---|---|---|---|
arch |
yes | yes | yes | yes | yes | yes | yes | yes | yes | yes |
Subversion | yes | yes | some1 | somewhat2 | no | no | no | no | no | yes (with add-on software) |
CVS | no | no | no | no3 | yes (with add-on software) | no | no | no | no | yes (with add-on software) |
Notes:
1 The Subversion designers are still working out
precisely what merge operators to include. The latest proposal is
advanced over CVS, but lacks several of the history-sensative merge
operators found in arch
.
2 In Subversion, it is easy to create branches and
there is no need to use tags or obscure revision numbers when
performing merges. So, that's much nicer than CVS. On the other
hand, Subversion lacks the intellegent merge operator
star-merge
, found only in arch
.
3 It is possible to develop on branches in CVS, but notoriously difficult and error prone.
atomic commits |
Can a developer check in a tree without risk that other developers, performing concurrent check-outs, will see the commit in an incomplete state? In other words, can an entire tree be committed to the repository in an atomic operation. Critically, atomic commits allow programmers to view a set of related changes to a tree as a single patch set, with a single log message. Additionally, atomic commits prevent developer confusion and permit accurate tagging of well-understood tree revisions. |
file renames handled cleanly |
Can developers rename files and directories without loosing the revision history of the renamed files, and without having to edit the repository by hand? Is the fact that files have been renamed "remembered" by the revision control system? File renaming is such a fundamental part of improving source trees that it is hard to believe that some revision control systems handle it poorly. Yet for historical reasons, CVS has problems in this area. |
advanced merging featues |
Does the revision control system keep track of what changes have already been merged and use that information to perform subsequent merges without generating spurious conflicts? Merging branches is fundamental to Open Source processes. A revision control system should do as much as possible to simplify this critical, time consuming, and error-prone task. |
easy development on branches |
Does the revision control system make it easy for developers to work on branches, merging changes to the primary trunk in controlled ways? If development on branches is difficult, programmers tend to make most changes on the primary "trunk". The result is that the trunk thrashes between working and broken states. A revision control system should make developing on branches easy and natural in order to foster a trunk that monotonically increases in features and quality. |
automatic ChangeLog generation |
Are revision control log messages automatically converted to ChangeLog files? Keeping accurate and informative ChangeLogs is tedious and, in the face of revision control logs, redundant. Automatic ChangeLog generation saves work and makes ChangeLogs more reliable. |
all revisions accessible as regular trees |
Can developers access all revisions as ordinary file system trees? This is a critical feature. By making all revisions available as ordinary trees, programmers are empowered to use every programming tool there is to explore, manipulate, and catalog those revisions. Without this feature, programmers are limited to only those functions built in to the revision control system. |
distributed and private repositories |
Are all branches constrained to live in a single, centrally administered repository? Or can different branches be stored in different repositories? Distributed repositories cut down on the number of programmers who need to be given write access to the trunk line. They ease the burdon on repository administrators. They permit programmers to have private repositories for day-to-day work. They permit distributed teams to have a collection of archives in various locations. They permit archives to be easilly mirrored. They permit programmers to get lots of work done while detached from all networks. |
easy server administration |
Does the revision control system have its own server or server modules and, thus, its own set of admistration head-aches? Or, does it piggy-back on servers most sites are already running? |
scalable |
As the number of branches and programmers grows, is the burdon placed entirely on a single server, and a single server administrator? |