22

I am in the process of knowing Mercurial versioning system better, and I am considering convert from SVN.
Anyone already converted? Was that difficult for you and your team to switch? Can you give any advice to stay with SVN or go for Mercurial?

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
twk
  • 3,122
  • 2
  • 26
  • 36
  • Can someone confirm the Mercurial is really slower than SVN? Sure, the local commits are fast, maybe just networked hg repositories are quite slow? – twk Feb 26 '10 at 19:59
  • And what about repository access through https? I will put it on Win2K3 server. – twk Feb 26 '10 at 20:00
  • @twk: if hg is slower than svn, that's a bug. – tonfa Feb 26 '10 at 21:37
  • Actually, I have heard that mercurial benchmarked slightly slower than svn at it's network pushing of commits, since svn is optimized for every commit having to be a network commit, though I think that time is easily regained by having fast local commits available. In most other ways mercurial is probably going to be faster, though. – Kzqai Feb 27 '10 at 00:00
  • Keep in mind SVN 1.7 is coming around the middle of the year with a promise of Git / Mercurial stlye DVCS functionality: http://subversion.wandisco.com/component/content/article/1/44.html – Troy Hunt Feb 27 '10 at 00:22
  • @Tchalvak even that, except maybe for the initial clone which will fetch the whole history. Network transfer of a single commit is (or should be faster). – tonfa Feb 27 '10 at 08:51
  • Link found below, pasting it up here, because it's brilliant. Thanks whoever posted this: http://hginit.com/00.html – Warren P Mar 18 '10 at 20:40
  • @WarrenP The article is written by no other than Joel Spolsky, one of the two founding fathers of StackOverflow... And it's a fun and quirky article, as usual :) – Cristian Diaconescu Apr 04 '13 at 08:58

3 Answers3

17

Once you start, you'll never want to go back. The advantages are huge.

I intentionally avoided branching under SVN, because every merge required hours of tweaking. Now, I look forward to branching because it works so well. It has made developing new features so much easier.

Furthermore, the ability to work offline is fantastic.

This SO article covers the conversion process in detail (its quite simple). You'll be able to preserve your history, but benefit from a DVCS.

This SO Question deals with DVCS benefits in detail, so I'll mention a Mercurial specific advantage. If you use a GUI like TortoiseSvn, you'll be pleasantly surprised by TortoiseHg. This app is continually improved and makes it very easy to view your pending changes and historical changes. It took a while to get to this level of quality, but now, I hate using TortoiseSvn, because it is just worse when it comes to reviewing pending changes and deciding what you want to commit.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
Michael La Voie
  • 27,772
  • 14
  • 72
  • 92
14

I don't have experience with mercurial (use git instead) but the difference in experience between a good DVCS like mercurial or git vs. svn is something that you truly can't go back from once you've gotten past the learning curve.

  • Local commits free up your workflow, your approach to coding features determines when you commit instead of your commits affecting how you work.
  • Svn's linear revision numbers are -bad-. Commits (especially with branches) simply do not correspond well to a simple incrementing mapping.
  • Local branches make compartmentalizing features much easier and better, prototyping becomes much simpler.
  • (only slightly related, but) Working offline tends to allow you to make changes faster than your competitors.

I had a job recently that involved going back to using a centralized svn repository after using git for a year or two. I approached it by using the git-svn bridge, and found that I had great control over the commits compared to svn, and could make the commits and branches sit, roll over, and play dead in ways that gave me a useful advantage over my svn using co-workers, in addition to the large volume of commits that I made by comparison because of the very granular and frequent nature of doing local commits. It was a great benefit.

I really really recommend giving yourself some time with a DVCS.

Kzqai
  • 22,588
  • 25
  • 105
  • 137
  • 3
    Local commits are not unique for DVCS's. They are just not implemented on other systems yet. Support for them is planned in +- Subversion 1.8. – Bert Huijben Feb 28 '10 at 21:08
6

I converted. At first it was just to try it out but I have become a big fan. I didn't actually convert my personal repositories, I just exported the latest and added the files to a new Mercurial repository.

Some of the basic hg commands are similar to those in svn so that should help you start getting comfortable. Here is an explanation of the differences from Joel.

Importantly, be open to using a new process with hg. It allows much more branching and quick committing, you'll get the most out of hg if you use break out of the subversion mindset.

Sam
  • 28,421
  • 49
  • 167
  • 247
Steven Lyons
  • 8,138
  • 1
  • 28
  • 27
  • 1
    I like the article, it tackles the big issue immediately: svn branching is hard, so it discourages committing works-in-progress, hg branching is easy, so it encourages committing/saving all your work. That ends up being a really big thing. – Kzqai Feb 27 '10 at 00:05