arch Feature Comparisons

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

arch, CVS, and Subversion, briefly compared
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.

Comparison Categories Defined

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?