tags:

views:

667

answers:

3

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?

Thanks

+9  A: 

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.

Michael La Voie
thanks for your response. +1
twk
+8  A: 

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.

Tchalvak
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
+4  A: 

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.

Steven Lyons
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.
Tchalvak
thanks for your response. +1
twk
Brilliant article by joel. thanks for posting that
Warren P