No matter how important you might think it is, you should not migrate your version control system when you switch to a fancy new system.
Something I see again and again is a team wanting to switch from CVS/VSS/TFS/SVN to something better, like SVN/git/BZR/Hg. In preparation for this move, they spend a lot of time seeing if they can find some tool that can migrate their history to the new system. After considerable effort, they decide it is no tools can do it well, and go ahead and do the switch manually. After some initial bumps, everyone is happy with the new system, and the team realizes that they haven’t missed the history at all.
So, my suggestion for anyone wanting to switch is this:
- Install the new VCS
- Make the old VCS read-only
- Make the first commit in the new system as just the trunk from the old system, sans all .svn/.ssc/.cvs files.
- If you need to look at old history, the old VCS is still there
If you have branches, merge them in before doing this. If you have long-lived branches that you want to keep after the switch, you probably have to do some manual magic. Do it manually. Don’t spend any time looking for tools.
Of course, you will not listen to this advice, and spend a number of fruitless hours looking for something that can do the switch for you. I know I would…
The exception being when the new VCS comes with a tool for doing the migration. For instance a simple “git svn clone ” is just as easy as creating a new git repo from your old svn head.
Left by Kerry Buckley on April 30th, 2009
NO! You are wrong. Don’t commit your trunk as the first commit! Use a tool to migrate your history. Holy crap. It is dead easy. There is a migration tool for every VCS. The future maintainers of your open source project will thank you. Having to dig in some old crufty VCS for history is very annoying, and if your project is of any decent size, you will be inconveniencing many people.
Left by RJ Ryan on April 30th, 2009
This is always easy to say until you find that the old cruft is one more thing to maintain (and no one wants to babysit the red headed step child). Or that you need to browse the old history and don’t remember the commands and really wish that the old vcs has some source tracking features some of the new version control systems have.
I’ve personally converted a monstrous history and it’s come in handy more frequently than I had originally anticipated. Besides, it was not that difficult and it’s only a one time cost. More mindspace to work on more pressing matters down the line, I personally think, is worth the effort.
Left by MF on April 30th, 2009
I have had to revive servers that hadn’t been plugged-in for three years to recover history that wasn’t migrated. Reattaching that box to the network and finding a client that worked on XP and still talked to the version of the server software was hard.
Migrate history if possible. Relegate it to its own read-only project if you must. But IS and the poor engineer tasked with recovering it in the future will be much happier with you if you can migrate and officially decommission the old server instance.
Left by Jeremy on April 30th, 2009
The first time you try to run `git blame` or some such on your new repository is when you will curse and start wasting the next hour or so digging through the old repo.
Left by l.m.orchard on April 30th, 2009
i can see this working fine on an agile project with a fairly active codebase with plenty of refactoring (where the history is less important), but on a more traditional project where most code tends to stay the way it was written (bugs and all) for most of it’s life the history is really, really useful.
Left by Anonymous on April 30th, 2009
I am glad to hear different opinions.
Kerry: Didn’t know that. If it works well, you should probably use it.
RJ: I haven’t had the experience you describe. And, truth be told, I was aiming at the corporate user, as that is almost exclusively where I am. Maybe there’s a difference there?
MF: I know that I haven’t missed it at all, any of the times I’ve done exactly what I describe here.
Jeremy: I’m claiming that even though you might in the future want to see the history, the cost of migrating is much bigger than the gain of doing it.
L.M. Again, I don’t share your experience. I rarely use blame. I think the last commenter might be right on target – in an agile environment, stuff move around quite a lot, and so blame-history is pretty unreliable.
Thanks for sharing your opinions!
Left by Andres on May 2nd, 2009
The dissertation writing service will offer people with the phd thesis but the professional idea just about this good post scholars would notice only on this page.
Left by YV29Chloe on January 24th, 2010
wow gold
wow gold
Left by wow gold on March 9th, 2010