cvs2svn requires the following:
cvs2svn does not support conversion of CVSNT repositories. Some people have indicated success with such conversions, while others have had problems. In other words, such conversions, even if apparently successful, should be checked carefully before use. See the FAQ for more information.
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.
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.
If you have many diverse projects in your CVS repository and you don't want to move them all to Subversion at once, you may want to convert to Subversion one project at a time. This requires a few extra steps, but it can make the conversion of a large CVS repository much more manageable. See How can I convert my CVS repository one module at a time? on the cvs2svn FAQ for a detailed example on converting your CVS repository one project at a time.
Pros:Allows multiple projects in a single repository to convert to Subversion according to a schedule that works best for them.
Cons:Requires some extra steps to accomplish the conversion. 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 subdirectory 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.There are two ways to specify the options that define a conversion: via the cvs2svn command line, or via an options file. The command line is useful for simple conversions, but the options file method is recommended for nontrivial conversions as it gives the user more flexibility.
A command-line conversion allows the use of all of the command line options listed below (except for --options). This method allows almost all of the built-in conversion options to be selected, with the primary limitation that it does not support multiproject conversions. However, it may require a long command line to specify all of the options for a complicated conversion.
The options file method allows full control of the conversion process, including multiproject conversions. It also allows expert users to customize the conversion even more radically by writing Python code. Finally, the options file used in the conversion can be retained as permanent record of the options used in a conversion.
To use the options file method, you need to create a file defining all of the options that are to be used for the conversion. A heavily-commented sample options file, cvs2svn-example.options, is included in the cvs2svn distribution. The easiest way to create your own options file is to make a copy of the sample file and modify it as directed by the comments in the file.
To start a conversion using an options file, invoke cvs2svn like this:
$ cvs2svn --options=OPTIONSFILE
Only the following options are allowed in combination with --options: -h/--help, --help-passes, --version, -v/--verbose, -q/--quiet, -p, --dry-run, and --profile.
|
USAGE: cvs2svn [-s svn-repos-path|--dumpfile=PATH] cvs-repos-path cvs2svn --options=PATH |
|
| --help, -h | Print the usage message and exit with success. |
| --help-passes | Print the numbers and names of the conversion passes and exit with success. |
| --version | Print the version number. |
| --verbose, -v | Tell cvs2svn to print tons of information about what it's doing to STDOUT. |
| --quiet, -q | Tell cvs2svn to operate in quiet mode, printing little more than pass starts and stops to STDOUT. This option may be specified twice to suppress all non-error output. |
| --options=PATH | Read the conversion options from the specified file. See section options file method for more information. |
| -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 PASS | Execute only pass PASS of the conversion. PASS can be specified by name or by number (see --help-passes) |
| -p [START]:[END] | Execute passes START through END of the conversion (inclusive). START and END can be specified by name or by number (see --help-passes). If START or END is missing, it defaults to the first or last pass, respectively. |
| --existing-svnrepos | Load the converted CVS repository into an existing Subversion repository, instead of creating a new repository. |
| --dumpfile=PATH | Output the converted CVS repository into a Subversion dumpfile instead of a Subversion repository (useful for importing a CVS Repository into an existing Subversion repository). PATH is the filename in which to store the dumpfile. |
| --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. |
| --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:
|
| --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. |
| --encoding=ENC | Use ENC as the encoding for filenames, log messages, and author names in the CVS repos. This option may be specified multiple times, in which case the encodings are tried in order until one succeeds. Default: ascii. |
| --fallback-encoding=ENC | If all of the encodings specified with --encoding fail, then fall back to using ENC in lossy 'replace' mode. Use of this option may cause information to be lost, but at least it allows the conversion to run to completion. Default: disabled. |
| --force-branch=REGEXP | Force symbols whose names match REGEXP to be branches. |
| --force-tag=REGEXP | Force symbols whose names match REGEXP to be tags. This will cause an error if such a symbol has commits on it. |
| --exclude=REGEXP | Exclude branches and tags whose names match REGEXP from the conversion. |
| --symbol-default=OPT | Specify how to convert ambiguous symbols (i.e., those that
appear in the CVS archive as both branches and tags).
OPT is one of the following:
|
| --symbol-transform=PAT:SUB | Transform RCS/CVS symbol names before entering them into Subversion. PAT is a Python regexp pattern and SUB is a replacement pattern using Python's reference syntax. You may specify any number of these options; they will be applied in the order given on the command line. This option can be useful if you're converting a repository in which the developer used directory-wide symbol names like 1_0, 1_1 and 2_1 as a kludgy form of release tagging (the C-x v s command in Emacs VC mode encourages this practice). A command like cvs2svn --symbol-transform='([0-9])-(.*):release-\1.\2' -q -s SVN RCS will transform a local CVS repository into a local SVN repository, performing the following sort of mappings of RCS symbolic names to SVN tags: 1-0 → release-1.0 1-1 → release-1.1 2-0 → release-2.0 |
| --username=NAME | Use NAME as the author for cvs2svn-synthesized commits (the default value is no author at all. |
| --fs-type=TYPE | Pass the --fs-type=TYPE option to "svnadmin create" when creating a new repository. |
| --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. (Note that unless it is removed explicitly, the last CVS revision number will remain associated with the file even after the file is changed within Subversion.) |
| --mime-types=FILE | Specify an apache-style mime.types file for setting svn:mime-type properties on files in the Subversion repository. |
| --auto-props=FILE | Specify a file in the format of Subversion's config file, whose [auto-props] section can be used to set arbitrary properties on files in the Subversion repository based on their filenames. (The [auto-props] section header must be present; other sections of the config file, including the enable-auto-props setting, are ignored.) Filenames are matched to the filename patterns case-sensitively unless the --auto-props-ignore-case option is specified. |
| --auto-props-ignore-case | Ignore case when pattern-matching auto-props patterns. |
| --eol-from-mime-type | For files that don't have the kb expansion mode but have a known mime type, set the eol-style based on the mime type. For such files, set the svn:eol-style property to "native" if the mime type begins with "text/", and leave it unset (i.e., no EOL translation) otherwise. Files with unknown mime types are not affected by this option. This option has no effect unless the --mime-types option is also specified. |
| --no-default-eol | Files that don't have the kb expansion mode and (if --eol-from-mime-type is set) unknown mime type usually have their svn:eol-style property to "native". If this option is specified, such files are left with no eol-style (i.e., no EOL translation). |
| --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. |
| --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. |
| --skip-cleanup | Prevent the deletion of the temporary files that cvs2svn creates in the process of conversion. |
| --profile | Dump Python Hotshot profiling data to the file cvs2svn.hotshot. |
| --svnadmin=PATH | If the svnadmin program is not in your $PATH you should specify its absolute path with this switch. |
| --co=PATH | If the co program (a part of RCS) is not in your $PATH you should specify its absolute path with this switch. (co is needed if --use-cvs is not specified.) |
| --cvs=PATH | If the cvs program is not in your $PATH you should specify its absolute path with this switch. (cvs is needed if --use-cvs is specified.) |
| --sort=PATH | If the GNU sort program is not in your $PATH you should specify its absolute path with this switch. cvs2svn requires GNU sort; Windows sort.exe is not adequate. |
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 --dumpfile DUMPFILE CVSREPOS
To use an options file to define all of the conversion parameters, specify --options:
$ cvs2svn --options OPTIONSFILE
As it works, cvs2svn will create many temporary files in the current directory (or the directory specified with --tmpdir). 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.