I've been using Mercurial for personal projects and I've really been liking it. I do a lot more branching and merging with it and it feels faster because of local commits.
We looked at few solutions at our startup and we decided to go with git instead of Hg after we launch (we'll use svn until then). I actually liked both and liked Hg a bit more due to its simplicity but since the Rails world has adopted git and everyone's distributing code using git and github, the decision was basically made for us.
We're in the same boat. We've been using Subversion, but will switch to git once our tools support it (we eat our own dog food, and Subversion is the only revision control system our products support right now). The determining factor for us was similar, as well...the Perl core developers appear to be moving to git for all Perl development. We're a mostly Perl shop, so we'll go where Larry and Co. goes. It just insures that the tool-chain for working with our codebase with git will be really solid, if the majority of Perl developers are also using it.
You know about the git svn bridge, right? It comes right in the standard git distribution, works intuitively and easily, and is the only thing keeping me sane as I work on two projects managed in Subversion. Basically, I use git in my development environment, with all the slick branching, merging, and great performance. Then I push code out to Subversion, and it all just works.
It seems as though Linus (he wrote git right?) has successfully performed his coup of the version control systems. Ok, not really, but its surprising that he could change what was thought to be an essentially solved problem with cvs and then svn. I would have never thought that someone could come up with a better CVS, but then SVN came out. Then came Git, and then this. Just goes to show that even problems that seem "solved" might have better solutions given a different set of situations.
Ahh... I knew Git was basically started with that Bitkeeper war, but since I don't really follow linux politics much as I don't use it all that often, I didn't realize that hg was started then as well. They seem very similar in their paradigm shift away from the central repository style of CVS and SVN. Is that a coincidence or was Bitkeeper also in this everything is a branch method?
I think it was Bitkeeper's solid decentralized workflow that convinced Linus that VC would even be feasible for kernel development; hg and git were written after people realized that they could no longer do without the features that Bitkeeper had.
Never would have thought that someone could come up with a better cvs? Really? I bumped into cvs' limitations the first time I committed a badly named file.
Also, making it out like the history of open source version control tools goes cvs -> svn -> git -> hg is missing a lot of history. (Get it?)
There are some others, too, like darcs, arch, bzr, and probably others.
I'm super conservative about version control. I'll wait until there's one clear winner, the bugs have been ironed out, lots of tools have been written for it, sourceforge/google code/etc... support it, and so on. I'll save my exploration time for other things.
I haven't used Mercurial, but I highly recommend darcs over git. The only advantage git has (which may be important to you) is it is much faster. Interactive recording on darcs is a joy to use.
darcs user interface is a joy to behold - it's far easier to get up and running than git, and easier on a day-to-day basis. However even on a one man project, I found that darcs performance problems started to bite after a few hundred check-ins (darcs unrecord being an obvious problem). IMHO this isn't a rare problem with darcs - any reasonably sized project is likely to hit this at some point. I also managed to get my darcs repositories into an unusable state several times just by pushing cherry-picked patches between them, which wasn't fun.
I miss darcs in some ways, particularly as getting running with git is a pain in the rear end. Fortunately darcs-git http://ftp.frugalware.org/pub/other/pacman-tools/pacman-tool... emulates enough of darcs user interface to sweeten the pill, and is definitely a good way to get started with git. I've also found that some of the functionality available in git but not in darcs has been very useful (even if it is typically a pain to work out how to use it).
any more info on using darcs-git? Looks like a python script that implements darcs user interface functionality on top of git without any need for darcs.
Mercurial rocks. We use it at the startup I work for, and it has been invaluable. Being able to swiftly and easily make your own branches is fantastic for prototyping.
I'm currently considering switching from Darcs to Mercurial or possibly Git. I've had problems with Darcs taking vast amounts of time to commit larger files and I'm assuming that both Merurial and Git (especially) will be much better at that.
I'm leaning more towards Mercurial at the moment because while I don't use Windows much myself I do want to be able to work with people who do.
Both git and hg are very nice, you will not go wrong with either one. If Windows support in the near future is a priority, you should probably use Mercurial. It works well today. The Windows port of git is coming along, but I don't know how long it'll take to reach first-class citizen status.
That said, if you don't need to deal with Windows, I suggest using git. It has a more power-user feel to it than Mercurial, and it has a few spectacular features I can't live without: rebase, stash, and the git-svn bridge. I'm also rather fond of git's lightweight branch mechanism. I know hg supports a variant of rebase and stash using the Transplant and Queues extensions, but the last time I looked at hg svn, it wasn't ready for use.
Also, when you read about git, you'll hear a lot of first-time users complaining about "the index." Just remember to think of it as a staging area for commits, and you'll be fine. It was a bit confusing at first, but then I realized that I like using it for making granular commits and diff checking.
