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

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 i开发者_如何转开发dea 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?

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.

Edit : Great Link - http://whygitisbetterthanx.com/

==========================================================

Yes, infact we have just moved from SVN to Mercurial.

Aside from the distributed side of things Mercurial and GIT are alot faster than SVN, and also the repo doesnt have annoying .SVN folders in ever folder. Not to mention the merge works alot better! The fact yuo can also store your repo on any shared drive is nice (No need to install stuff on the server, for Mercurial anyways)

More reading

Should I use SVN or Git?

http://www.richappsconsulting.com/blog/blog-detail/svn-vs-git-who-will-be-the-future-of-revision-control/

http://thinkvitamin.com/code/why-you-should-switch-from-subversion-to-git/

http://techblog.floorplanner.com/2008/12/09/git-vs-svn-for-bosses/

And finally GIT Vs Mercurial

http://gitvsmercurial.com/ - This site looks like it's dead now :(

1. Merging code and resolving conflicts is easier using a distributed VCS like GIT or Mercurial. The reason is that GIT or mercurial have all the intermediate snapshots of the two "end codes" to be merged while subversion would only know the end snapshot unless each SVN user is working in his/her own branch.

2. With a distributed VCS, you are not dependent on the network to check code in.

3. If you have a large number of users checking stuff into VCS on a daily basis, your SVN server better be very powerful to handle concurrent check-ins/outs. DVCSs dont have that problem.

We made our switch from CVS to SVN and now to Mercurial and we are very happy with the transition. There is nothing about SVN we are missing in Mercurial but going back to SVN would be painful.

Things SVN has that might be important to your workflow:

1. Partial checkouts.
   Can just checkout part of the tree (important if you have more than 1 project in your repository)

2. Mixed checkouts.
   Parts of your checkout can be at different revisions, down to a single file.

3. Globally unique revision is monotonically increasing.
   It's easy to see in SVN that rev 1206 is later than 1100 (c.f., is cfbb0827c67d later than d500c208c3c5?)

4. Many projects can share the same SVN repository.
   If your package consists of several EXEs, DLLs and whatnot, in Hg/Git land you may end up using several repositories to manage this. This can complicate tag/revision handling somewhat

We (Nokia OVI maps) are also migrating from SVN to HG. The reason to choose HG over git is that HG is more userfriendly, the commands make much more sense compared to the sometimes obscure git commands. Also for windows users mercurial works much better, and tortoiseHG is quite mature. When I was testing git on windows, I observed serious performance problems at some simple operations like checking for modifications...

I really like also that you can use features that you want via extensions. So the learning curve is smoother than with git, consider the cache area for example. For people coming from SVN I think HG is good option.

They should be more careful with the history for example, we are encouraging to do hg pull --rebase in order to have history as linear as possible and merge only branches.