Would you migrate from cvs to svn or directly to git or hg?

Question

I don't know if this is the right forum to ask.

My company makes use of CVS as a version control system. We plan to move to a more modern version control system. What would you recommend as the least risky solution?

My idea is to use Subversion but I also hear a lot of good things about Git and Mercurial

However, we are a small company and we don't need a distributed version control system. What advantages do Git or Mercurial have with respect to Subversion, besides the fact that they are distributed?

Answer 1

We migrated from CVS to Mercurial about 2 weeks ago at my job. We are a small team of 6 people. Only two of us had already worked with something other than CVS prior to the migration.

I was in charge for the choice of the new CVS. I considered Git and Mercurial.

Some of the griefs we've had with CVS were poor branching possibilities, no support for renaming, really bad algorithm for conflicts.

I never considered SVN because, each time I tried to use it with branches in the past, merges were always a headache. And frankly, all the hype is for dvcs these days, and there must be a reason about it ;)

Between Git and Mercurial, it's really more about personal choice. My heart fell for Mercurial because I've found it easier to learn than Git and less "really big project" oriented.

Advantages of Git / Mercurial over SVN

1. Better branches and merging capabilities (really the most important reason)
2. Possibilities to export / import patch in bundles, via e-mail, etc
3. Didn't do extensive tests about that, but I think both are faster in many ways than SVN (merging, cloning, diffing, etc)
4. Development is much more active, I heard the SVN team is trying to move forward, but still.
5. Really good extensions infrastructure
6. Shipped web server capability, really useful for quickly sharing something for example.

And even if you said "besides the fact that they are distributed", I think this is really a killer feature. DVCS allows some really neat things, it may not seem useful at the beginning, but once you've used them, you can't do without them ;)

Learning curve

Two people on the team weren't really happy about the change. But with a little two hour explanation for the whole team with some slides, everything went smoothly.

Sure, they ask me questions sometimes, but we haven't had any real problems since the migration. Just some little misunderstandings about the way to merge pulled changes in the working directory. Nothing which wasn't resolved in a matter of minutes.

I think I can say that in just about 2 weeks, everyone is at least as productive as before and confident with the new tool. And now we can use features branches without fear of the merge to come :)

Migrating CVS to mercurial

https://www.mercurial-scm.org/wiki/RepositoryConversion#CVS

Different methods are listed on the official wiki about migrating from CVS to Mercurial. I tested the Convert extension and cvs2hg which was finally used.

The Tailor extension, hg-cvs-import, from CVS seems to be old code and not maintained any more.

The Convert extension works just fine on a simple repository, but since our CVS repository was really big and had some really strange branches, the extension wasn't able to import correctly all of the history. The HEAD was correct, but some branches were missing.

So, the last choice is cvs2hg. In fact it is a new backend for cvs2svn, which converts to Mercurial instead of Subersion.

The 'Quick start' approach presented in the Readme worked out of the box with all the branches. But finally I used the option file to add some user mapping and prune some buggy commits or unwanted branches.

The option file in the provided with the files is well commented, it won't be hard for you to configure it to suit you.

For information, after the initial conversion, I used the Convert extension to do some subproject extraction from the resulting Mercurial repository to another Mercurial repository, like explained here.