Hi again, I wanted to echo Iavor's comment that you shouldn't feel 'obliged' to use darcs out of Haskell brand loyalty. Try both systems out and see how they feel. My enthusiasm is really about what I find to be a great and very comfortable workflow. You'll have to see for yourself what suits you best. More importantly... On Sun, Mar 01, 2009 at 10:40:46 +0000, Eric Y. Kow wrote:
Why I love darcs ================
One of the darcs team members, Thorkil Naur, felt that in my enthusiasm I was not being sufficiently forthright about darcs's shortcomings. First, I would like to express my gratitude to Thorkil for calling me out. Second, I wanted to state unequivocally that darcs, no matter how much I love it, is not perfect.
It's not just that it's written in Haskell; it's that the whole thing is driven by something which is very clean, powerful and which delivers a concrete impact in the real world.
When I said this, I was focusing on one idea: namely that most of the darcs user interface is just as straightforward consequence of two operations: patch inverse and patch commutation. In my eyes, that was very clean, the whole of darcs basically just boils down to these two operations. What I failed to add is that /defining/ how patches should commute is not so beautiful. The problem occurs when patches conflicts; the question of how patches should commute when they conflict is still not completely well understood. We have some working ideas: code for darcs-1 and darcs-2 patch theories which seems to work reasonably well. But to call it clean and elegant would definitely be a stretch. Furthermore, darcs has bugs, some of which are fairly deep (where conflicts or duplicate patches are involved). Some of these bugs are documented and some we have only recently discovered, and some may be looming just around the corner. So far, these bugs have not affected a lot of repositories, and in those cases, it has been fairly straightforward to recover from them. But know that they are there.
We now have a stable and more sustainable development team (I'm working on 20% darcs time at my job with the University of Brighton and have committed myself to spending no more than 8 hours a week on darcs to avoid burnout; a lot of our jobs have been assigned to dedicated managers -- hello!) and are adopting some new practices (hacking sprints, 6-month time based release schedule) to keep development running more smoothly.
Another reason to be concerned about the darcs team is that since David Roundy retired from darcs life, we do not have anybody who deeply understands darcs, that is, all the way down to the inner workings of a darcs repository (for example the manipulation of the pending patch) and to its patch theory core. We have folks like me who have a rudimentary understanding of patch theory (i.e. who grasp the relationship between commutation, inversion and merging and who also understand some of what darcs-1 conflicts are), but what we lack are people who deeply understand the darcs-2 core (Ian Lynagh's work on camp is actually quite similar to darcs 2, so in a sense, he does understand it), especially as it's implemented. This puts us in an awkward position, one of not being able to quickly work through any fundamental bugs if they should arise. We would have to scamper up that learning curve fairly quickly. But I'm still optimistic over the long term. These things will come. We've made a lot of progress building up our community infrastructure, and we are learning how to make better use of our time. For what it's worth, a few of us on the team will be focusing on darcs fundamentals during the sprint. We need more testing, we need to look at our deep bugs more closely and we need to learn our way through darcs's guts. And I think we can do it. Thanks, Eric PS. We have started a fundraising effort to get folks to the darcs hacking sprint. More details on that shortly. -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9