views:

72

answers:

3

My employer has tasked me with becoming our new version control admin. We are currently using two different version control systems for two different code bases. The code/functionality in the two code bases overlap in some areas. We will be moving both code bases to a new version control system.

I am soliciting ideas on how to do this. I suppose we could add the two code bases to the new version control as siblings in the new depot's hierarchy and gradually remove redundancy by gradually promoting to a third sibling in the hierarchy, ultimately working out of the third sibling exclusively. However, this is just a 30,000 ft view of the problem, not a solution. Any ideas, gotchas, procedures to avoid catastrophe? Thanks

A: 

Issues to consider:

  • How much history will you migrate?
  • How long will you need to continue using the old systems for patch-work, etc?
  • How long will you need to keep the old systems around to access historical information?
  • Does the new target VCS provide an automatic or quasi-automatic migration migration method from either of the two old VCS?
  • How will you reconcile branching systems in the two old VCS with the model used in the new VCS?
  • Will tagging work properly?
  • Can tags be transferred (which will not matter if you are not importing much history)?
  • What access controls are applied to the old VCS that must be reproduced in the new?
  • What access controls are to be applied to the new VCS?

This is at least a starting point - I've no doubt forgotten many important topics.

Jonathan Leffler
+2  A: 

Git can be setup in such a way that svn, git, and cvs clients can all connect. This way you can move over to a central Git repo, but people who are still used to svn can continue to use it.

It sounds that in your specific situation, with two code-bases you want to combine, you should make three repositories and start to combine the first two into the third one.

Apreche
+1  A: 

My advice is to experiment with a few "test" migrations. See how it goes and adjust your scripts as necessary.

Then once your set, you can execute it for real and your done. Archive your old repos too.

Another place you might find inspiration is OpenOffice.org. They are in the middle of going from SVN to Mercurial. They probably have published information on their migration work.

Frank V