cvs2darcs http://ab-initio.mit.edu/cvs2darcs/ cvs2darcs is a script to check out a CVS repository module and convert it to use the Darcs version control system (http://www.darcs.net/). In order to use it, you must have the cvsps utility installed (http://www.cobite.com/cvsps/) (cvsps is used to extract the CVS patch history). cvsps version 2.0 or later is strongly recommended. You will also need Darcs, CVS, and Perl installed, as well as the HTTP::Date Perl module from libwww. To install cvs2darcs, do: ./configure make install which will install it in /usr/local/bin. (To install it somewhere other than /usr/local, use ./configure --prefix=). You can also run cvs2darcs directly from the source directory (after running ./configure). Then, for a cvs module , the basic usage is: cvs2darcs This checks out into a new directory and converts the directory into a Darcs repository. Run 'cvs2darcs -h' for more options. For example, you can pass the standard cvs -d option to specify the location of the repository. ----------------------------------------------------------------------------- Developer Notes If you are setting up cvs2darcs from the cvs2darcs Darcs repository, you will need to create the configure scripts etcetera before doing anything. Run: autoreconf --verbose --install --symlink --force (You'll need automake and autoconf installed on your system.) To create a version for distribution (so that end-users don't need automake/autoconf), create a cvs2darcs-.tar.gz file with: ./configure make dist You should *not* edit the cvs2darcs script; instead, edit cvs2darcs.in and re-run ./config.status. ----------------------------------------------------------------------------- Documentation of Internal Perl Scripts cvs2darcs is a shell script that, internally, calls two Perl scripts written by David Roundy and Ganesh Sittampalam, called cvs_convert.pl and branch_detect.pl. The following text documents the direct usage of these scripts (which was how these scripts were originally used). The two scripts are installed in /usr/local/share/cvs2darcs/ (or whatever the installation prefix was). In order to run the scripts, you need a CVS checkout of the project you're importing. As far as I know, it doesn't actually matter what state the checkout is in. To import HEAD: darcs initialize /path/to/cvs2darcs/cvs_convert.pl /path/to/cvs/checkout This will produce lots of output. Inspecting it might provide some idea of what's going on. To import another branch, you need to import the "parent" up to the point of the fork, then import the child branch (this procedure needs to be applied recursively until you get to HEAD) /path/to/cvs2darcs/branch_detect.pl /path/to/cvs/checkout This will produce output like this: devel: 3 (HEAD) nick: 140 (devel) HEAD: ganesh: So, to import the nick branch we need to first import HEAD up to patch 3, then devel up to patch 140, then nick: /path/to/cvs2darcs/cvs_convert.pl -l 3 /patch/to/cvs/checkout /path/to/cvs2darcs/cvs_convert.pl -l 140 -b devel /patch/to/cvs/checkout /path/to/cvs2darcs/cvs_convert.pl -b nick /patch/to/cvs/checkout Known/possible bugs: cvsps seems to cache things over-aggressively. If it seems to be ignoring recent changes, try deleting the contents of ~/.cvsps cvsps sometimes merges two independent checkins that occurred close to each other in time. This is a known and unavoidable problem that isn't too serious on its own; however if both checkins change the same file, the changes will be reported in reverse order, which confuses things. I'm not sure that cvs_convert.pl is deterministic; there are possibly some weird interactions to do with process timing that can cause trouble. This needs proper testing. If you have a CVS changelog formatted in a particular (fairly unlikely) way, it'll confuse things. See the comments about bugs in the scripts. Because CVS sets up branches at the per-file level, it's possible to make a branch that starts from the middle of a patchset. branch_detetct.pl will report such a branch as "INVALID". Also, if a file is created/modified on HEAD (or any other parent branch) after a branch is created, and later merged into that branch, then the branch needs those changes, but they are lumped in with changes that the branch musn't have. Both of these problems make it pretty much inevitable that partial changesets will need to be created for the child branch that are subsets of full ones on the parent branch.