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
  • 923
  • 7
  • 16

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,878
  • 11
  • 125
  • 168
  • +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 Dec 07 '10 at 12:09
  • 1
    +1 IMO the best strategy. Keep using just one, the others in read-only-mode just in case. – user281377 Dec 07 '10 at 12:10
  • 1
    +1: more accurate answer on the migration part. – VonC Dec 07 '10 at 12:47
  • 1
    +1 - hard enough to understand the existing code let alone the last three versions. – JeffO Dec 07 '10 at 13:02
  • +1 @JeffO, @VonC: I agree, in other words I think @ChrisF's answer is about scoping the problem, containing it, defining its boundaries, as well as search vs organising as I originally said. – therobyouknow Dec 07 '10 at 13:18
  • -1 I think this is an awful advice. "Just drop the entire history of the project", really ? What's the point ? – barjak Dec 07 '10 at 13:19
  • @barjak - I didn't say "drop" the entire history. Just archive it. As I also said this was personal experience of several moves, one from VSS to Perforce the others between Perforce depots. I think we only ever had to go back to the archive on a handful of occasions. – ChrisF Dec 07 '10 at 13:23
  • @ChrisF : did you run into troubles while trying to convert a repository ? – barjak Dec 07 '10 at 13:42
  • @barjak - the biggest issue was time. While the tools existed and did their job we determined that it would have taken too long to convert keeping the histories. After that initial experience we didn't even bother when switching Perforce depots/servers. – ChrisF Dec 07 '10 at 13:50
  • 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 Dec 08 '10 at 12:31
  • +1 @JBRWilkinson about reality on not looking too far back. – therobyouknow Dec 09 '10 at 09:38
  • Accepted answer as from experience and about not worrying about migrating one source system to another, answering my question directly about how to migrate. @barjak came close also with his very good point on tolerating more than one system, it is possible i think. also credit to @VonC for the detail on things to consider. – therobyouknow Dec 22 '10 at 21:42
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,484
  • 2
  • 20
  • 19
  • +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 Dec 07 '10 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.

barjak
  • 1,720
  • 12
  • 18
  • 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 Dec 07 '10 at 14:57
  • PS. +1 Lucky you, barjak, for being in an organisation that tolerates a varied computing environment. – therobyouknow Dec 07 '10 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.

JeffO
  • 36,816
  • 2
  • 57
  • 124
  • +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 Dec 07 '10 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 Dec 07 '10 at 18:17