In this article, we will look into the process of migrating from other version control systems to Subversion.
Development teams decide to switch to Subversion for a wide variety of reasons. For many, SVN delivers new and desirable features which were lacking in their former system - usually because that system's design was much older than Subversion's. Such is the case with CVS, and for some commercial systems as well.
The second most frequent reason is the total cost of ownership. With commercial systems, companies usually pay surprisingly high yearly fees to get support and upgrades. In times of intense competition and shrinking budgets, this expenditure can be hard to justify if you see that you can get the similar features for free with Subversion.
The last common migration reason, which usually combines with the two just mentioned, is that some systems offer complex features which, while not utilized by the team, still generate some extra work - by requiring users to do simple tasks in a complicated way, for example.
Version Control Babel and the Effect on Migration
Every version control system has its own approach to the problem domain, and it's own concepts and semantics. Some names have completely different meanings in different systems ( checkout, for example), while similar concepts often have different names in different systems (like revision and version).
Moreover, each system usually has a more or less different style of working, or provides a different way of performing the same use case, compared to other systems. People not aware of this usually ask questions like "How can I do XXX with Subversion?" and are not prepared to get answer like "In your system you do XXX only as a part of YYY, but in Subversion YYY is done in a completely different way and therefore it doesn't make sense to do XXX."
For a successful migration, always keep the above diversities in mind and be prepared for the potential problems they can cause. The biggest problem - completely disqualifying SVN from consideration due to misunderstanding of the concepts - probably will not be the case with you if you have been following this series of articles (or if you will go back and check them out).
A second common problem faced in migration is when the innovator (the person or persons who did the research on version control systems and selected the Subversion as the alternative) needs to convince the rest of the team about SVN's suitability for the given purpose. The innovator speaks the languages of both Subversion and the old system, while the rest of the team usually speaks just the language of the old system.
Another common problem is failure to adjust the development process/workflow to fit the new repository. Sometimes the process was designed to fit some way of working imposed by one version control system. In such cases, the process will need some adjustments to completely utilize the features of Subversion.
To avoid the complications described above, it is crucial not to underestimate the psychological aspects of the migration process. Change forces people out of their "comfort zone" - so it's a good idea to help people establish a new one by doing team training on Subversion features and concepts before the actual migration takes place, and by discussing beforehand all aspects of the change, including how to do things in the new environment. This kind of collective brainstorming activity can result in even more improvements than those suggested by the innovator alone.
During the time period between the training and the actual switch