Have you converted from subversion to mercurial? Was it worth the effort?

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

  • Mercurial: How to ignore changes to a tracked file
  • Git style backup of binary files
  • What's the Mercurial equivalent for git hash-object and how do I get the hash of a certain commit?
  • call for insight: revision control and binaries
  • git submodule from Hg repo?
  • ISO a version control tool that can manage files that are NOT under a directory tree marked as managed by the VC tool
  • subversion merge - “has different repository root than”
  • Replicating svn:externals with git
  • To where should I point the VCS root of TeamCity?
  • git-svn clone file integrity
  • SVN to GIT migration without TRUNK in repository
  • Is it possible to link SVN repository files so that a file is actually a reference to another repository's file?
  • 3 Solutions collect form web for “Have you converted from subversion to mercurial? Was it worth the effort?”

    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.

    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.

    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.

    Git Baby is a git and github fan, let's start git clone.