So yes, while you can certainly use darcs in medium-sized projects, you need to take some precautions in doing so. Apparently, darcs users fell into a habit of avoiding the pitfalls semi-subconsciously. But you can't expect newcomers to the tool to be able to do that, and they are much more likely to end up in one (or more) of such pitfalls.
I think you're on to something there. I've been using darcs on multiple repos for years and mostly it has been and remains a joy; I love it. This contrasts with the painful stories we hear now and then from other darcs-using projects. Usually they are the ones without a resident darcs expert.
My biggest repo has 50M of content. My oldest has 2000 patches and 20 contributors, but typically at most 2 are active at one time. I don't do a whole lot of branching. I definitely learned to try and avoid high-conflict situations, when after a few years of use my darcs 1 repos started getting exponential record/pull times. I resolved it then by re-recording conflicting patches as a single new one. My motto then was "no conflicts in the repo!".
Converting to darcs 2 format seemed to resolve this but I have mostly kept the habit. For example I try to pull from upstream before recording, so that I can deal with a conflict there and then, rather than record a separate conflict resolution patch. It's not that I feel this is necessary with darcs 2, but it keeps the history cleaner and life simpler.
One thing I have experienced, is that when I do run into problems with a darcs, they are almost certainly "shallow" in the sense that once I find out what's going on it is pretty easy (a) to undo/recover/resolve it and (b) to reason about. This is key; it's easy for me to understand what happened at every step and be confident that the repo contains what I think it does. I find this much harder with other rcs's.
-Simon _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
