You've omitted Stellation:

http://eclipse.org/stellation/

Jim s.

There is also Bitkeeper, very popular in the opensource community,
free for opensource projects.

For a list of cvs alternatives see http://mindprod.com/jgloss/cvs.html

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Meta-CVS supports renaming. Yet it's layered on CVS and so gives you
almost exactly the same model of version control; if you know how to
use CVS, there isn't all that much to learn.

The key difference is that the directory structure of the project is
mirrored in a versioned element. So when you perform a ``mcvs up'',
you can pick up not only changes to file contents, but a patch to your
directory structure. The update operation figures out the difference
between the previous and the new structure, and rearranges your
sandbox accordingly. Files appear and disappear or are moved.

You can have ``local edits'' in the directory structure that you merge
with new changes from the repository. Conflicts can occur which can be
resolved by editing text. Directory structure changes are committed in
the usual way.

Jars are derived elements; you should version the original .java
files. If you have third-party jars that your project depends on,
these probably change very little, so you probably won't be storing
many versions of them.

PDF's: again, probably generated from some text-based markup that you
really want to be versioning.

Meta-CVS handles difficult corner cases that the Subversion people
haven't even thought of. Consider what happens when developers are
modifying, adding, removing and renaming files in parallel, and
integrate these changes.

You get problems like the same file being renamed in two different
ways in parallel. Or two unrelated files get moved to the same name.
Or you have a file with local edits, do an update, and it is deleted.

Meta-CVS addresses such cases by design. For instance, consider the
last case when someone deletes a file that you have locally edited,
and you pick up the delete when you do your pre-commit update. In
Meta-CVS, deleting a file is not handled by ``cvs remove'' but rather
by unlinking the file from the directory structure. It's purely a
directory structure edit. When you pick up such an edit, that file
disappears from the sandbox, but the underlying element still exists,
and even retains all your outstanding local edits! You can commit that
element, so your work is not lost. You can re-enter that element into
the directory structure, possibly under a different path, if you so
desire. It's the same object, so none of its history is lost at all.
You can merge to it from some branch that was made long ago where it
has a different name, etc.