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?

Improve this question

4 Answers 4

Reset to default
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.

Improve this answer
12
  • +1 fair point, only migrate what you need, leave the old versions in the legacy previous repository. Don't migrate for its own sake. This approach is a variation of the approach to the choice between organising versus searching. If searching can get you what you want quickly, everytime then there is no need to organise what you search.
    – therobyouknow
    Commented Dec 7, 2010 at 12:09
  • 1
    +1 IMO the best strategy. Keep using just one, the others in read-only-mode just in case.
    – user281377
    Commented Dec 7, 2010 at 12:10
  • 1
    +1: more accurate answer on the migration part.
    – VonC
    Commented Dec 7, 2010 at 12:47
  • 1
    +1 - hard enough to understand the existing code let alone the last three versions.
    – JeffO
    Commented Dec 7, 2010 at 13:02
  • 1
    We converted many CVS repositories to SVN using the cool cvs2svn script, which worked really well. I don't ever recall anyone looking up the history beyond 'recent changes', so this wasn't actually worth the diskspace. If I did it again, I'd just tag the CVS repo, check in to SVN as new and then mark the CVS repo as read-only.
    – JBRWilkinson
    Commented Dec 8, 2010 at 12:31
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.
Improve this answer
1
  • +1 good answer, bullet points outline the criteria I'm looking for, and your explanations with them help too. I'll give others a chance before accepting an answer. Thanks.
    – therobyouknow
    Commented Dec 7, 2010 at 12:06
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.

Improve this answer
2
  • Need for integrating different systems ? Yes if the work of one team is used by another team. The integration can be tight or lose depending on the level of necessity and staff resource available. No if the projects are completely independent. The only remaining concern is supporting more than one system and whether that is perceived to be a good or a bad thing. Good if we accept that we live in a varied computing world or bad if we think that we should focus and show decisiveness for their own sakes, by choosing one tool itself that might be overly solipstistic!
    – therobyouknow
    Commented Dec 7, 2010 at 14:57
  • PS. +1 Lucky you, barjak, for being in an organisation that tolerates a varied computing environment.
    – therobyouknow
    Commented Dec 7, 2010 at 14:58
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.

Improve this answer
2
  • +1 A realism here. People need to hold their nerve, be brave and proceed. Risks need to be well defined. One learning I'm seeing and hearing other people say in my workplace is that sometimes we don't work hard enough at reducing the uncertainty/clearly defining the risks/contigencies before we engage. It would seem that there is plenty of time for the get-it-wrong/fix iteration but not enough time to get it right first time. Fixing problems is rewarded and seen as activity in progress, even if sometimes they were unnecessary.
    – therobyouknow
    Commented Dec 7, 2010 at 13:20
  • 1
    That depends on the VCSs in question and how well the migration is done. Moving from Git or even CVS to any locking VCS is going to be extremely jarring.
    – David Thornley
    Commented Dec 7, 2010 at 18:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.