to SVN, the team members need to get used to the changes. Creation of a "sandbox" repository, where developers can safely explore the new environment can be a huge help in establishing a new comfort zone. As a bonus, it is possible to utilize the changes necessary to adopt the new system (SVN in our case) to heal some bad habits of the development team as well.
A typical company or development team has a huge amount of different kinds of data under version control. The gamut ranges from "old" projects, which are no longer being developed and which are not even accessible any more (because they were created using a legacy version of the version control system, for instance), to "obsolete" projects, which are not used any more, on up to the actual active projects.
The migration process itself costs something, and therefore it is usually not wise to migrate every single versioned file in the whole company. It's clear that to migrate any data, they must be readable. Therefore the first mentioned are out of scope. It can be helpful to classify existing data into three categories:
- Data that will not be migrated (such as legacy, unreadable data)
- Data for which only the HEAD (without history, tags, labels, etc.) will be migrated
- Data which will be fully migrated, including history, tags, labels, etc.
These categories can be based on frequency of their usage, frequency of modifications, and overall expected future use.
Migration of the second category is trivial - it means only exporting data from the old system into plain files and then importing those into SVN as any other new files from the file system.
Migration of the third category is usually the most complicated and time consuming part of the whole process, so let us take a close look at how you might approach it.
Migrating files with the history
This requires translation of data and concepts between different systems and therefore a special utility is needed. There are a number of them available online; most are able to process just one source system (like cvs2svn).
The most complete and mature utility seems to be SVN Importer ( http://polarion.org/), which is an open source project sponsored by Polarion Software. SVN Importer can import data from CVS, PVCS, ClearCase, Visual Source Safe, and MKS. It's completely implemented in Java, and its modular structure allows possible addition of other source systems. The number of features varies for different source systems (CVS and PVCS being the most completely covered). New features and fixes are being continuously added, so coverage will improve with time. Even so, the migration process in not a simple and fast wizard-like procedure; it does require some tuning of the configuration for each individual case.
With some limitations, SVN Importer can also be used for incremental import of changes in a source repository, providing a way to keep SVN in sync with the another repository during a period of time.
SVN Importer Schema
The schema of SVN Importer's operation is shown on the picture. With exception of CVS, the importer always requires the source repository software to be installed on the computer, and it uses the command line tool to access the source data.
In the first conversion step, all source data are analyzed and the source repository model is created. Next, the source model is transformed into the Subversion model. This process is highly sensitive to inconsistencies in the source repository. Even small problems, which can remain unnoticed during normal operation, usually come to light here, since all data are traversed. Such