The converse to merging two repositories into one is to take a single repository and split it into two separate repositories. To illustrate, let’s say that instead of two repositories namedfooprojandbarproj, you start with a single repository namedfoobar_repos
that contains both projects (in root directories namedfooprojandbarproj, respectively). Now, let’s say that those projects have grown extremely large, and your server no longer has the power to serve both projects. So, you decide that because the projects don’t share much, it would be easiest to just split them into two different repositories and serve them from separate servers.
The best way to accomplish a repository split is by using the toolsvndumpfilter. Withsvndumpfilter, you can dump a repository and either include only paths that begin with a set of prefixes or exclude paths that begin with a set of prefixes. In our case, we want to create two repositories from two different root directories, so we’ll run the dump filter twice and include only the project we want each time, as in the following example steps.
9.3 Migrating an Existing Repository 129
1. Create two new (empty) repositories to hold each of the split repositories.
$ svnadmin create /srv/fooproj $ svnadmin create /srv/barproj
2. Dump the original repository and run it through a filter that will only include the
fooprojproject directory. Then, load that into the newly created repository.
$ svnadmin dump /srv/foobar_repos | svndumpfilter include --drop-¬
empty-revs --renumber-revs /fooproj | svnadmin load --ignore-¬
uuid /srv/fooproj
• Using the --drop-empty-revs and --renumber-revs options with
svndumpfilterwill cause the revisions of the newly created repository to be collapsed down, with any revisions that didn’t include changes to thefooproj
project removed. If the revision numbers are important to you, you can cause Subversion to leave them the same by leaving out those two options.
• The--ignore-uuidoption is important, because Subversion will set the repos- itory UUID to the UUID from the dump file if you are loading into an empty repository. You don’t want your two newly create repositories to end up with the same UUID though, so--ignore-uuidwill tell Subversion not to change the UUID. Because the UUIDs of the repositories will change, users of the repository will have to check out new working copies from the appropriate new repository.
3. Repeat the dump and load to populate thebarprojrepository.
$ svnadmin dump /srv/foobar_repos | svndumpfilter include --drop-¬
empty-revs --renumber-revs /barproj | svnadmin load --ignore-¬
uuid /srv/barproj
9.3
Migrating an Existing Repository
Sometimes, a Subversion repository will be created as part of a brand new project. In those cases, getting initial data into the repository is easy—there is none. More often than not, though (especially because Subversion is so new), a new Subversion repository will be part of a migration away from another version control system. As part of that migration, there is a whole history of data that most people aren’t going to want to lose. Therefore, the ideal solution is to be able to take the entire repository history from the old system and migrate it over to Subversion.
The two most common version control systems that people migrate to Subversion from are almost certainly CVS and Microsoft’s Visual SourceSafe. This has led to the creation of migration tools that allow you to take repositories from both systems and create a Sub- version repository that preserves the history of all of the files in the old repository.
“svnbook” — 2005/4/14 — 14:55 — page 130 — #151
i i
130 Chapter 9 Organizing Your Repository
9.3.1
The Basic Migration Process
Whatever the system that you are migrating from, there are a few things that you should always remember. Failure to heed these warnings will not harm pets or small children, but could result in loss of data, or even loss of a job.
• Always back up your existing repository before attempting any sort of migration. Just because the migration tool shouldn’t mess with your old repository doesn’t mean that, if something bad happens, it won’t.
• Always back up your existing repository before attempting any sort of migration. Just because the migration tool shouldn’t mess with your old repository doesn’t mean that, if something bad happens, it won’t. (Yes, I meant to say that twice.)
• Have a migration plan. Do you intend to move everyone over to Subversion imme- diately? If not, are some people going to continue using the previous system as their primary VCS while others migrate completely, or is everyone going to mirror all of their changes into both systems during a transition period?
• Keep the old repository around, just in case. Until you are positive that your new Subversion repository is going to work out, make sure that you can go back to the old system.
• Test everything in the new repository after the migration. Make certain that the HEAD revision of your repository is correct and working inside the Subversion repository. It might even be a good idea to run a diff on all of the files in a working copy of your Subversion repository, to make sure they match the files from your old VCS.
• Know what you’re losing. Because the VCS that you’re migrating from is not Sub- version, it doesn’t store exactly the same things that Subversion does. Invariably, some data (however minor) will be lost in the transition. Make sure you know what you are losing, and store it somewhere else if it’s important to keep (properties may be a good place to store information that you want to save).
9.3.2
Migrating from CVS
If your existing project source is stored in a CVS repository, you are in luck. Thecvs2svn
utility provides excellent conversion tools for migrating a CVS repository to SVN, while preserving most (if not all) of your history data. You can even import data from a CVS repository into an existing Subversion repository that already contains other data, and can pick and choose exactly which data you want to import.
You can acquire cvs2svnfrom the project’s Web site,cvs2svn.tigris.org. The program is a Python script, so it doesn’t require any installation, and can run on either MS Windows or a UNIX-like system, as long as you have Python and a couple of other prerequisites installed. To find out exactly what you need to install, you can look at the officialcvs2svndocumentation on the project’s Web site.
9.3 Migrating an Existing Repository 131