12

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?

Martin Geisler
  • 72,968
  • 25
  • 171
  • 229
Alain
  • 323
  • 2
  • 11
  • 1
    I'm not sure what being small has to do with not "needing" a DVCS (nor why you talk about what you need rather than what would be best). There are plenty of questions here about the advantages of DVCSes that you might find illustrative. (And in fact, the ease of branching and merging mentioned in Krtek's answer is something that tends to always be present in a DVCS.) Search for `[dvcs]` and you'll see plenty. – Cascabel Mar 01 '11 at 14:09
  • 1
    note he's very careful to say "tried to use it with branches *in the past* " as Subversion has addressed a number of it's merge issues and from what I've read they will fix the remaining issues this year. – vinnyjames Mar 01 '11 at 23:19

5 Answers5

19

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.

rishi
  • 2,564
  • 6
  • 25
  • 47
krtek
  • 26,334
  • 5
  • 56
  • 84
  • Glad to hear that. Does there exist tools to migrate CVS repositories to Mercurial? – Alain Mar 01 '11 at 10:47
  • there's plenty of way of doing this. I quickly edit my response to add a little something about this – krtek Mar 01 '11 at 10:50
6

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 :(

Community
  • 1
  • 1
LiamB
  • 18,243
  • 19
  • 75
  • 116
4

  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.

Yasser
  • 1,808
  • 12
  • 18
  • In my experience, subversion is not up to any serious merging and screws up anything non-trivial. I'd disagree with the explanation, though. Subversion has all data it needs, but it's object model mixes branches and directories which does not allow simple definition of merge parents, leading to complex implementation with bugs in corner cases. On the other hand the distributed model is based on merging, so it's easy and reliable in all the distributed systems. – Jan Hudec Mar 01 '11 at 10:42
  • Say 2 devs are working in the same branch. In SVN they would probably be careful in checking code in frequently because they know they share the repository and dont want to create commit/update issues for the other person. When they are eventually ready to check-in, you have two snapshots of code that need to be merged together but no history of how the code got to those 2 tips. In DCVSs, you would probably check code in more frequently because you know its into your local repo only and wont break it for anyone else i.e. when u are ready to merge, you have two histories to merge. – Yasser Mar 01 '11 at 10:53
3

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

Martin Geisler
  • 72,968
  • 25
  • 171
  • 229
bobbogo
  • 14,989
  • 3
  • 48
  • 57
  • I totally agree with 1 and 2. But 3 is partially "wrong", at least for Mercurial, sure each revision has his unique hash, but it also has a _local_ incremental revision number. And I honestly didn't understood your 4. – krtek Mar 01 '11 at 11:05
  • @Krtek: 3 explicity says _globally unique_—i.e., a number you can publish in your realeased binaries. The local revision does not cut the mustard here. The Hg equivalent would be tagging I suppose. I'll update point 4. – bobbogo Mar 01 '11 at 11:27
  • Yeah right, sorry I skipped the globally. Like you said yourself, tagging can be a workaround, but I agree with the point. – krtek Mar 01 '11 at 12:08
  • **partial checkouts** are more about not checking out large files you are not working on; if you have more than 1 projects in repo this means (at least for DVCS) that you did it ***wrong***. – Jakub Narębski Mar 01 '11 at 13:06
  • @Jakub: Agreed. This answer though is intended to give the svn view of these things. It is most definitely _not_ a mistake to have lots of things in your svn repo. – bobbogo Mar 01 '11 at 16:33
  • @bobbogo: partial checkouts if used to have more than 1 project in repo are not advantage; they are just a way of doing things (which has some nasty side-effect wrt. to the ways you can screw your repo history by accident in Subversion). – Jakub Narębski Mar 01 '11 at 23:08
  • @Jakub: Again, agreed. I wasn't chalking it up as an advantage. It is a different way of working (and a different way of scewing up) from the way you drive Hg/git et. al. Never the less, it is still valid. (It is quite nice to tag various revisions of projects and have them and their history in one place. Not for all projects, but some.) – bobbogo Mar 02 '11 at 14:58
0

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.

piotr
  • 5,657
  • 1
  • 35
  • 60