I tried Darcs quite some time ago, but like Bazaar I didn't have anything I wanted to use it on at the time. I like Darcs' relatively small command set, and it didn't take me long to be able to use it. But I never really used it, and it's the workflow that most concerns me. I notice they do have a best practices document, which is nice.
Other than that, I don't really know why to choose one over the other. My interest in Bazaar is in part the implementation language, and that it is backed by a real institution. But, I must admit I am also impressed by Darcs' implementation language; it really seemed to set off a lot of true productive Haskell programming. This comparison doesn't find Bazaar better in many ways, though many Darcs items are blank (someone should fill them in).
I think Bazaar probably has the most potential of success if it can act just like Subversion, except with nice merging. Then people can use other features incrementally, but Subversion (or the CVS model more generally) is the proper starting point (at least from a marketing point of view). Which leads one to svk. Which is also easy to type than bzr or darcs.
OK -- use svn, and then use tailor to export it as a distributed project ;).
The only real solution, I think, is to actually use one or the other. Try contributing to twill, why not? ;)
My brief experiences with svk were:
- It was very, very slow.
- It fell over with odd errors.
- It had even worse documentation than most other [RV]CSs I've encountered.
Having worked mostly with Bazaar and CVS, the one thing about CVS I miss with Bazaar is the documentation, particularly examples. Being told over and over again that some special name or token I'm using is invalid, without any documentation about what is actually valid, really annoys. Having to trawl various blogs, some being out-of-date, just to find stuff out also really annoys.
It's a shame because someone has clearly made an effort to write nice help texts for the baz commands. If only they'd realised that examples would mostly complete the job and reduce developer stress by 95%. I hope they've figured that out with bzr...