I recently wrote an article or two about distributed version control systems.
I’ve been using Darcs since 2005. I switched to Darcs, in fact, 10 days after the simultaneous founding announcements of git and Mercurial.
Overall, I have been happy. I continue to believe that it is the most distributed of the distributed VCSs, which is a Good Thing.
However, I have lately started having trouble with Darcs hanging while working on my Debian packages. My post to the Darcs user list drew out a few other people whith this problem, which is a design flaw of Darcs.
So I revisited the VCS landscape. I re-examined git, Mercurial, and bzr. I eventually decided to give Mercurial a try. I avoided git because I write some code that is portable to Windows, and git isn’t (or isn’t very well). Also, git is complex to pick up for me, and I certainly don’t want to force something complex onto my contributors. bzr seemed to still have some strange behaviors that it’s had for awhile, and I couldn’t find even one advantage of it over Mercurial. So off I went with Mercurial.
I quickly learned a bit of a philosophical difference from Darcs to Mercurial.
Darcs avoids conflicts at all costs. Mercurial makes handling conflict easy and, in many cases, automatic.
It is exactly this Darcs behavior that permits both is excellent “darcs send” feature (still unmatched in any other VCS), but also causes its hang problems.
I found Mercurial quite pleasant to work with, and *fast*. It seems to be edging out git in speed tests sometimes these days.
It is easy to get started with Mercurial. The mq system — similar to quilt or other patch-management programs — is really quite an amazing hybrid between patch management and version control. I frankly don’t see any need for other patch-management tools anymore.
Mercurial has a “patchbomb” feature where you can select a range of changesets to send off, and it will generate nice emails with one changeset per email, and send them to your selected destination, optionally with an introductory message. The normal way of interacting with other Mercurial users is via the hg export/import commands, which send around simple unified diffs plus some additional header information, optionally in the git extended diff format.
I am happy with Mercurial and am in the process of converting my Debian repositories from Darcs to Mercurial. I’m going to keep my personal code in Darcs for the moment because “darcs send” is still easier than “hg email”, but that may change before long, depending on how my experience goes.
I’d encourage others to give Mercurial a try. The community is also very nice and helpful.
I have contributed patches to Tailor to make it make exact copies of Darcs repos into Mercurial, which are now in its Darcs repo. There is also a thread on the Mercurial list with some of my initial questions/concerns coming from a Darcs perspective.
Just out of curiosity, what behaviour of bzr do you find strange?
See the story and comments here: [url]http://changelog.complete.org/posts/528-Whose-Distributed-VCS-Is-The-Most-Distributed.html[/url]
Any special reason to use export/import instead of the more usual push/pull or even bundle to move changesets from one repo to another one?
It’s often more convenient to use export/import instead of push/pull. That way, contributors don’t have to have commit access to my repos, and they also don’t have to publish theirs on the web. bundle/unbundle would work too, but isn’t as easy for reading diffs.
I recently switched from Darcs to Mercurial (for [url=http://ikiwiki.info/]Ikiwiki[/url], which doesn’t yet support Darcs). I’ve found I’m having to spend a lot more time merging when I don’t ‘hg up’ before committing. Darcs handles it without a problem.
Darcs doesn’t really have very good windows support either… (says the happy darcs user)
Darcs has a few trick that hg can’t match. Like undoing a specific patch. Say you are at version 100 and want to remove the changes from version 70 to 71. Tricky with hg and many other scm’s. With darcs, you issue two commands: darcs rollback -p “Version70”; darcs revert. Done!
hg backout -m 71
After significant testing with pre-releases of Darcs 2, I’ve found that the “hang” problems are generally solved, as well as problems with “–partial” repositories, and other general improvements like making backup files in more conflict cases, improved SSH support, and generally better feedback when things do go wrong.
Pre-release binaries are available on the wiki for testing.
Also, I think the open bug count, currently about 75, along with the high number of automated tests for project are goods signs over the overall quality that darcs currently has.