Question

It looks like Mercurial is a bit less mature than Subversion. What are the benefits of Mercurial over Subversion and what was behind the decision to use Mercurial for Kiln?

If Mercurial is stable, it looks like a switch from SubVersion to Mercurial/Kiln would be pretty easy (install Python + TortoiseHG instead of Tortoise and then some kind of replacement for Ankh for VS integration and we'd be all good to go). Has anyone made this transition yet? Is it as simple as it sounds or are there some gotchas? Is there any way to import our existing code history?

Cheers, Jimmy

Answer 1

I am using Klin now - I came from subversion - and after a few days of das$##$#$ I love it now. Is very easy and if you use Tortoise SVN with TortoiseHG very few changes.

Answer 2

Distributed version control is different than SVN (or CVS). It takes you awhile to understand it coming from SVN, but basically the magic is it lets you branch. Branch all you want, branch whenever you want... the DVCS will figure it out for you. In the same way everyone switch to SVN from CVS, I suspect the migration will happen to DVCS.

Read more about branching in Mercurial...

Answer 3

There's a whole forum about Kiln at kiln.stackexchange.com. :)

Answer 4

Number one advantage - you don't have to be connected to anything or anyone to commit your code. When you detach from SVN, TFS and lots of other TLAs you can't commit any changes. Later, when you connect you can sync and merge but the disconnected functionality is the winner for DVCS. Git too.

Importing to Mercurial from Subversion is covered in their excellent guide at http://mercurial.selenic.com/wiki/RepositoryConversion#Subversion

I'm using Kiln & I like it. The KilnOverflow site is gaining momentum and is well-worth a browse.

Answer 5

Switching from SVN or any old-style system to a DVCS is definitely the way to go. You can read here: http://hginit.com/00.html an excellent explanation how the former hinders work.

However, transition is not painless and IMO benefits are expected only where there already exists a genuine want for the features (including easy branching, pick, merge, stash, et, and the question "do we want it" is replaced by "how we can manage the switch."

For the practical side, I recently made the switch at the company. From TFS to Git. I used a ton of thinking, and initially aimed for Mercurial, but eventually it lost the comparison. Unfortunately meaning we can't use Kiln, that we really wanted, and suffer from not-so supported integration with FB. (I really hope FC people will cover that gap in 1-2 years).

While Hg may be less mature than SVN, Git is definitely not. :) And fortunately its non-support for Windows is in the past.