[darcs-users] About darcs darcs repo as an darcs usage example...

Petr Rockai me at mornfall.net
Wed Mar 11 14:10:03 UTC 2009

Gwern Branwen <gwern0 at gmail.com> writes:
> I think this is a rather overgloomy asssessment.

> There are plenty of repositories which have hundreds of patches from
> many - dozens - of users, and which not infrequently branch off. To
> give an example, XMonad has 1061 patches and easily a score of
> contributors, and has branched off significantly several times (and
> sjanssen is currently branching off right now, for his monoid branch
> at http://code.haskell.org/~sjanssen/xmonad-newconfig); or take
> XMonadContrib, with over a hundred modules in it and even more
> contributors - we usually see patch conflicts only when the module in
> question genuinely has changed irreconcilably. Or take Yi, with 3416
> patches in it. I'm certainly in agreement that binaries aren't handled
> well, but I think Darcs shouldn't be disrecommended for medium-size
> projects. Can't say as us Yi and XMonad hackers have had many issues
> with Darcs!
Well, even the largest of your mentioned repositories is half the history size
of darcs. Also the largest (yi), among 3416 patches I have examined, has 0
conflict resolution patches (at least darcs changes -v | grep conflictor didn't
turn up a single line ... I have checked with darcs darcs repo and it has a few
dozens of such lines in its history). I wouldn't say that's exactly typical of
a project of that size. Maybe the fear of conflicts is not insignificant factor
in that effect?

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 am not saying other tools don't suffer from any problems. But among the
"mature" tools, to me, it seems that darcs is most prone to fall into a rather
painful kind of a trap, where you need to abandon branches, or do expensive
manual recovery/reconciliation.

Just to give you a pathological example of a project that used to be trying to
use darcs-1 as a "really" distributed (many divergent branches) tool:

darcs changes --count: 4564
darcs changes -v | grep merger: 849

Some of the merges are probably exponential (I haven't checked in detail).
Moreover, it hit some of the (plain) pristine corruption bugs. Add the
annoyance of conflict markup not being up to par in darcs... Result? Telepathy
(the project in question) is not using darcs anymore, and I guess they don't
have very pleasant recollections of its usage.

As for how that relates to darcs-2 -- I don't know. In my experience, darcs-2
(repository format) is harder to predict and more buggy than darcs-1, although
it does fix the pristine corruption issue (but that is also the case with
hashed format), as well as part of the merging slowness (but not all of it). It
might be that with issue1043 fixed, darcs-2 format is more reliable, but I'm
afraid it's already lost much credibility.

Now of course, there is a reasonable chance, that within a year, we'll have
those issues sorted out and we will be right back directly competing against
git and mercurial. That however very much depends on available time in a few
people that would work on that happening.

I consider darcs-2 to be reasonable intermittent format, just I don't believe
it's a good permanent solution. We can probably cope with the bugs it has,
fixing what we can and working around the rest. However, from what I can tell,
the real problem of darcs currently is that the core code is a tangle no-one
really understands. We really need the core to be as transparent as possible
(and hopefully, that's also one of the objectives of camp-core).


Peter Rockai | me()mornfall!net | prockai()redhat!com
 http://blog.mornfall.net | http://web.mornfall.net

"In My Egotistical Opinion, most people's C programs should be
 indented six feet downward and covered with dirt."
     -- Blair P. Houghton on the subject of C program indentation

More information about the darcs-users mailing list