If you're looking to switch an existing CVS repository to Subversion, you have a number of choices for migrating your existing CVS data to a Subversion repository, depending on your needs.
There are a few basic routes to choose when switching from CVS to Subversion, and the one you choose will depend on how much historical data you want in your Subversion repository. You may be content to refer to your existing (soon-to-be-converted-to-read-only) CVS repository for "pre-Subversion" data and start working with a new Subversion repository. Maybe you prefer to squeeze every last drop of data out of your CVS repository into your Subversion repository. Then again, perhaps you want a conversion somewhere in between these two. Based on these needs, we've come up with these different recommended paths for converting your CVS repository to a Subversion repository.
If you decide that top-skimming doesn't meet your needs and you're going to use cvs2svn (yay!), then be sure to read the section below on prepping your repository before you start your conversion.
This is the quickest and easiest way to get started in your new repository. You're basically going to export the latest revision of your cvs repository, possibly do some rearranging, and then import the resulting files into your Subversion repository. Typically, if you top-skim, that means you'll be either be keeping your old CVS repository around as a read-only reference for older data or just tossing that historical data outright (Note to you data packrats who have just stopped breathing, please take a deep breath and put down the letter opener. You don't have to do this yourself--it's just that some people don't feel the same way you do about historical data. They're really not bad people. Really.).
Pros: Quick, easy, convenient, results in a very compact and "neat" Subversion repository.
Cons: You've got no historical data, no branches, and no tags in your Subversion repository. If you want any of this data, you'll have to go back into the CVS Repository and get it.
If you decide that you'd like to have the main development line of your historical data in your Subversion repository but don't need to carry over the tags and branches, you may want to skip converting your CVS tags and branches entirely and only convert the "trunk" of your repository. To do this, you'll use the --trunk-only switch to cvs2svn.
Pros:Saves disk space in your new Subversion repository. Attractive to neatniks.
Cons: You've got no branches and no tags in your Subversion repository.
Let's say, for example, that you want to convert your CVS repository's historical data but you have no use for the myriad daily build tags that you've got in your CVS repository. In addition to that, you want some branches but would prefer to ignore others. In this case, you'll want to use the --exclude switch to instruct cvs2svn which branches and tags it should ignore.
Pros:You only get what you want from your CVS repository. Saves a some space.
Cons:If you forgot something, you'll have to go to your CVS repository.
If you want to convert your entire CVS repository, including all tags and branches, you want a full conversion. This is cvs2svn's default behavior.
Pros: Converts every last byte of your CVS repository.
Cons: Requires more disk space.
Lastly, you can convert your repository (or repositories) piece by piece using a combination of the above .
Pros: You get exactly what you want.
Cons: Importing converted repositories multiple times into a single Subversion repository will likely break date-based range commands (e.g. svn diff -r {2002-02-17:2002-03-18}) since Subversion does a binary search through the repository for dates. While this is not the end of the world, it can be a minor inconvenience.
There are a number of reasons that you may need to prep your CVS Repository. If you decide that you need to change part of your CVS repository, we strongly recommend working on a copy of it instead of working on the real thing. cvs2svn itself does not make any changes to your CVS repository, but if you start moving things around and deleting things in a CVS repository, it's all too easy to shoot yourself in the foot.
If you want to convert a subdirectory in your repository, you can just point cvs2svn at the repository and go.
If there are any files that you don't want converted into your new Subversion repository, you should delete them or move them aside.
Lastly, even though you can move and copy files and directories around in Subversion, you may want to do some rearranging (typically of directories) before running your conversion.cvs2svn requires the following:
| USAGE: cvs2svn [-s svn-repos-path|--dump-only] cvs-repos-path | |
| --help, -h | Print the usage message and exit with success. |
| --version | Print the version number. |
| -q | Tell cvs2svn to operate in quiet mode, printing little more than pass starts and stops to STDOUT. |
| -v | Tell cvs2svn to print tons of information about what it's doing to STDOUT. |
| -s PATH | Load CVS repository into the Subversion repository located at PATH. If there is no Subversion repository at PATH, create a new one. |
| -p START[:END] | Start converting at pass START, end at pass END of 8. If only START is given, run only pass START (implicitly enables --skip-cleanup). |
| --existing-svnrepos | Only load the converted CVS repository into an existing Subversion repository. |
| --dumpfile=PATH | Convert the CVS repository into a Subversion dumpfile at PATH. |
| --tmpdir=PATH | Use the directory PATH for all of cvs2svn's temporary data (which can be a lot of data. The default value is the current working directory. |
| --dry-run | Do not create a repository or a dumpfile; just print the details of what cvs2svn would do if it were really converting your repository. |
| --profile | Dump Python Hotshot profiling data to the file cvs2svn.hotshot. |
| --use-cvs | If RCS co is having trouble extracting certain
revisions, you may need to pass this flag, which causes cvs2svn
to use CVS instead of RCS to read the repository. RCS is much
faster, so it's the default, but in certain rare cases it has
problems with data that CVS doesn't have problems with.
Specifically:
|
| --svnadmin=PATH | If the svnadmin program is not on your $PATH you should specify the absolute path to svnadmin with this switch. |
| --trunk-only | Convert only the main line of development from the CVS repository (commonly referred to in Subversion parlance as "trunk"), ignoring all tags and branches. |
| --trunk=PATH | The top-level path to use for trunk in the Subversion repository. The default value is "trunk". |
| --branches=PATH | The top-level path to use for branches in the Subversion repository. The default value is "branches". |
| --tags=PATH | The top-level path to use for tags in the Subversion repository. The default value is "tags". |
| --no-prune | When all files are deleted from a directory in the Subversion repository, don't delete the empty directory (the default is to delete any empty directories. |
| --dump-only | Convert the CVS repository to a Subversion dumpfile instead of a Subversion repository (useful for importing a CVS Repository into an existing Subversion repository). |
| --encoding=ENC | Use ENC as the encoding of log messages in CVS repos (default: ascii) |
| --force-branch=NAME | Force NAME to be a branch. |
| --force-tag=NAME | Force NAME to be a tag. This will cause an error if NAME has commits on it. |
| --exclude=REGEXP | Exclude branches and tags matching REGEXP from conversion. |
| --username=NAME | Use NAME as the author for cvs2svn-synthesized commits (the default value is no author at all. |
| --skip-cleanup | Prevent the deletion of the temporary files that cvs2svn creates in the process of conversion. |
| --bdb-txn-nosync | Pass the --bdb-txn-nosync switch to "svnadmin create" when creating a new repository. |
| --cvs-revnums | Record CVS revision numbers as file properties in the Subversion repository/dumpfile. |
| --mime-types=FILE | Specify an apache-style mime.types file for setting svn:mime-type properties on files in the Subversion repository. |
| --no-default-eol | Suppress cvs2svn's usual eol behavior, which is to set the svn:eol-style property to "native" on all files that CVS would do end-of-line translation for, namely, all files not marked with the kb expansion mode. With the --no-default-eol option, cvs2svn will only set svn:eol-style according to the --eol-from-mime-type option (see below). |
| --eol-from-mime-type | Set the svn:eol-style property to "native" on all files whose mime type begins with "text/", except those marked with the kb expansion mode. This option is meaningless unless --mime-types is also passed. There is also little point passing --eol-from-mime-type without passing --no-default-eol too, since without --no-default-eol, all non-kb files will get an svn:eol-style of "native" anyway, whether or not their mime type says to. |
| --keywords-off | By default, cvs2svn sets svn:keywords on CVS files to "author id date" if the mode of the RCS file in question is either kv, kvl or not kb. If you use the --keywords-off switch, cvs2svn will not set svn:keywords for any file. While this will not touch the keywords in the contents of your files, Subversion will not expand them. |
To create a new Subversion repository by converting an existing CVS repository, run the script like this:
$ cvs2svn -s NEW_SVNREPOS CVSREPOS
To create a new Subversion repository containing only trunk commits, and omitting all branches and tags from the CVS repository, do
$ cvs2svn --trunk-only -s NEW_SVNREPOS CVSREPOS
To create a Subversion dumpfile (suitable for 'svnadmin load') from a CVS repository, run it like this:
$ cvs2svn --dump-only --dumpfile DUMPFILE CVSREPOS
As it works, cvs2svn will create many temporary files in the current directory. This is normal. If the entire conversion is successful, however, those tempfiles will be automatically removed. If the conversion is not successful, or if you specify the '--skip-cleanup' option, cvs2svn will leave the temporary files behind for possible debugging.