11

Companies acquire other companies that use different version control systems.

Is there a common wisdom on how to integrate such systems together, for example using a Subverson-GIT bridge or even deciding on using just one tool over another - and how to migrate between systems?

Do people use a set of criteria for such decision making, for example an equivalent to the "Joel" test on software development?

therobyouknow
  • 933

4 Answers4

11

To answer the migration question from personal experience of several migrations:

Don't be afraid to just put the current version of the software into the new source control system as the base line and work from there.

The vast majority of the time you won't need the history. This means it's one less task to perform during the integration and one less thing to go wrong.

Files/projects that are being actively developed will soon generate a new history. So when you need to find out why a change was made the chances are that the history will be in the current repository as it will be a recent change.

Files/projects that were stable before the migration should (all things being equal) remain stable after the migration so you won't need to refer to the history. We found that if we had to investigate a bug in such an old file/project having the history wasn't really of any benefit. As long as you keep the old repository available for 6 months/a year you'll have the reference in such cases.

ChrisF
  • 38,948
  • 11
  • 127
  • 168
4

On the managerial side, it is mainly a question of:

  • support: will the company releasing the VCS still be there in case of trouble.
    It is sadly one of the main reason why such obsolete products like ClearCase are still considered (ClearCase being since 2003 an... IBM product)
  • license cost: even if there are freeware alternatives, sometimes "group licenses" for a VCS can be negotiated or actually included within a much larger contract including servers, networks, support, etc... A global licence for this kind of product can end up costing a lot less than the public price.

On the project side, it is also a question of:

  • administration: on which server will you install a VCS (or many VCS if we are talking about Git, SVN, and others)? With what backup policy? What DRP (Disastry Recovery Plan)?
  • local support: who will take the level 1 support,? level 2?
  • market knowledge: are you sure to find enough developers and/or administrators with the right knowledge set to leverage this VCS and all its feature?

Freeware or not, remember a "free" software is free as in "free speech" (you are free to choose and deploy the one you want), not as in "free beer" (it will still cost a lot of money in server, backup, administration, support, ...)

The criteria mentions above are a start to determine what VCS to keep, what to abandon.
But in the latter case, you need to consider:

  • migration strategy: can you export/import a project history from one VCS to another?
  • bridge strategy: does it make sense to have an history in two different VCS?
  • project obsolescence: if a project is in maintenance/End Of Life status, it might be better to support an old VCS for a short while.
VonC
  • 2,504
1

Do you really have a need for integrating different systems ? In our team, each project lives in its own repository, and their histories are thus independant. We have no problem here to work with some projects under subversion and some other under mercurial, even if there are dependencies between them.

If you choose to migrate from one VCS to another, look at the conversion tools available. There is, from my experience, no technical reason to drop the projects' histories.

Edit

I think I understood something, which was implicit in the question and in other answers. It's the fact that VCS are also used to manage dependencies. I know it's quite common to use VCS features like svn:externals to integrate one repo (the dependency) with another.

I think the (technical) reason our team doesn't feel the need to bridge (or integrate) our 2 different systems is that we have a separate tool to manage dependencies. Our repo don't know each other.

barjak
  • 1,740
0

Lot's of good answers. One other thing to think about is don't let team members get away with thinking switching the VC is such a big deal. There will be a setback with migration, a learning curve, etc., but if they have have too many problems, they need to question their level of ability and/or cooperation.

JeffO
  • 36,956