It should be possible to import the current FreeBSD CVS repository, and retain the following.

• A complete history of HEAD
• Every RELENG branch, mapped to the appropriate branching methodology of the target VCS
• If the target VCS supports atomic commits then commits to the CVS repo that would have been considered atomic by log_accum.pl should also be atomic in the new repository

It is not necessary to maintain the same per-file revision numbers. However, it is desirable that a mechanism be available to map from commits in the new repo to commits in CVS.

For example, it should be possible to say that src/README, r1.23, can be found at revision N (or changeset FOO) in the new repo.

N/A

There are several CVS → Subversion repository converters. The most well known is cvs2svn, written in Python, which ships with Subversion in the contrib/ directory. I am also aware of a converter by Polarion, written in Java (http://www.polarion.org/index.php?page=overview&project=svnimporter). I am not aware of any tests that have been run to determine how well these tools handle the FreeBSD CVS repository.

Hg's conversion tools are still a work in progress although mostly satisfying solutions do exist:

This is a general purpose converter between several VCS including CVS, bzr, Hg and others. It is rather slow but gets the work done. I have not tried it on src or ports as they are too big IMHO. Branches and tags are not supported AFAIR.

This is the most advanced solution yet. This is the converter that we use on [http://hg.fr.freebsd.org/ HG repos]. The original one does not support branches at all but Pierre Beyssac (pb@) hacked it in.

It takes three days to convert src and more than 12 days to convert ports. Please keep in mind that we need to do that only once per branch and fortunately, ports is not branched at all.

We have CURRENT and RELENG_6 on hg.fr.freebsd.org.

This is a new converter written by Chris Mason (who also wrote the Mercurial Queues extension). It is using [http://www.cobite.com/cvsps/ cvsps] to massage the CVS repository into individual changesets which are then imported to Hg.

cvsps does not seems to support all the pecularities found in our repos because it dumps core on src.

This is a new converter written by Simon “corecode” Schubert who is also the author or cvs20hg. It is based on his implementation of rcsparse and is written in Ruby. Not yet tested on our repos.

NOTE: cvs20hg is the only one supporting (apart from fromcvs which is not finished) branches right now.

Like git it could also be a valid way to convert our repos but I'd say only if all others fail.

Git's conversion-from-CVS tools are still a work in progress. There are a few options:

This should be ignored. It uses cvsps, which totally mangles your history

This tool does a good job of mapping CVS history into atomic commits. However, the current algorithm is O(revisions * files) in memory, which is too much on repos of our size (died on an i386 with 3GB of RAM). We think we can get it down to O(revisions + files) or so, which should be doable.

The problem here is that there have been many reports of cvs2svn getting the history wrong. One of the features of parsecvs is that I understand its methods, and its methods sound pretty solid. Also, the cvs2svn conversions are quite time-consuming (several days on mozilla, from what I understand, which is about twice our size), so doing repeated imports to get a sample repository output that you like is rough.

Partially Supported (also see [http://venge.net/monotone/wiki/FeatureCVSImport monotone:FeatureCVSImport])

[“Monotone”] can import cvs history, including collecting together changes in multiple files into synthesised change sets. The cvs_import command provides this feature; this is just one of several ways of working with Monotone and CVS.

The primary limitation the cvs_import command is that CVS branches are presently not attached to the revisions they branched off from: each is an independent linear history. Work is underway to resolve this limitation.