With the shining review of git just posted, it seems there would be little ground left for other tools to show distinction.
However I respect and admire darcs on several grounds, and there are still clear and useful development interactions for which darcs has an advantage over all current git porcelainù.
It's also properly distributed
Firstly, it should be noted that almost all of the distributed development advantages of git also apply to darcs. darcs also uses a single directory for its repository, so 'grep -r' is ok from sub-directories, and like git, it keeps these repositories with the checkouts so you can freely move and copy your checkout directories without worrying about using special commands or updating some mapping file in an obscure location in your dotfiles.
darcs has not been scaled to massive projects, instead focusing on smaller ones (say, a few thousand commits), where the extra functionality is considered more important than speed. That being said, in fact you'll see in newer darcs repositories the first traces of content hashing, which have made drastic improvements - and could eventually render git's performance edge marginal.
The (in)famous Patch Calculus
Patch Calculus has to be one of the most frighteningly named terms used in revision control systems today. It screams "Maths to University Level required to understand".
But let's throw away the awful term and describe it in plain Geek. Basically it's all about ways of determining, from a set of possibly unrelated patches, which extra patches are required for any given "cherry pick". I much prefer terms like Patch Dependency to refer to this set of concepts. Even darcs' term patch commuting could be better called patch re-ordering.
The theory goes like this. If you are trying to get a specific change from a tree, then quickly work out by examining the history which other changes are required first, and so add all of those patches to your tree.
The general finding from this technology is that it is useful, but it opens a big can of worms. In essence, the version control system is tracking not only the history that you recorded, but also all the different paths through the patches you have made that history might have successfully progressed. And on any code base, simple metrics such as "does this patch apply cleanly" cannot be relied upon to verify whether or not two changes are actually interdependant.
So, what some developers do is manually mark which patches are predecessors to the next patch that they make. Even more enlightended developers use metrics such as whether or not the changed code still compiles successfully or even passes the regression test suite to consider changes dependant.
Whether patch dependency works or not in practice depends on whether or not developers create commits of a high enough standard that they co-operate with this feature.
Interactive Commit
I didn't talk about this much in the SVK section despite SVK having this feature, mainly because darcs is where the feature came from in the first place.
Basically, the way it works is when you record changes, you are presented with a summary of the changes, then asked to group each change, hunk by hunk into bundles which are darcs patches.
This is largely how it is possible for the patch calculus to work so well - if changes to a single file are combined into a single commit as so frequently happens with file-grained commit in other VCS, it entwines the two features being worked on to be co-dependant. The better the tool is at keeping changes small and tidy, the better - but if they are too small, the reverse happens - every feature is considered to be its own independant change.
ù - And now darcs is a git porcelain, too
With the arrival on the scene of darcs-git, a git porcelain with the UI of darcs, I have access to the interactive commit interface of darcs already.
I don't miss patch dependency, because it is easily - and I would add, less confusingly - performed with git using topic branches (making a new branch for each new feature or stream of development), and the powerful tools of rebasing and cherry picking.
