[darcs-users] Benchmarking "get"

Stephen J. Turnbull stephen at xemacs.org
Tue Mar 17 10:34:54 UTC 2009


Max Battcher writes:

 > With darcs-2 repos I've yet to see any merges that have given me 
 > trouble.

 > At the moment, I've yet to see anyone post a bad example of a darcs-2 
 > conflict fight. The conflict issues may not yet be finally and truly 
 > solved, but it is important to repeat that progress has been made (and 
 > is continuing to happen). A lot of people are still being told to avoid 
 > darcs because of the conflicts situation and the community does need to 
 > trumpet the importance of darcs-2 format repositories.

Sure, nobody (here) is saying anything else.  The point is that if you
rely on your anecdotal experience to "trumpet" the improvements,
you're violating Karl's Principle of Pleasant Surprises.

 > I explicitly tied things to my own anecdotal workflows.

Which is a way of saying "YMMV".  That's not what people want to hear
about their VCS.

 > It doesn't matter to me if it works well at the super-huge
 > repository level if its a pain in the ass to use day to day.

Problem is, that Darcs as yet has little (published) experience at
even moderately large sizes, projects like Python or an Emacsen
(20~100 active committers, 20,000~100,000 revisions in all historic
branches).  The few experiments I've heard of at that size were all
done with Darcs 1, so totally obsolete.  And most of the developers I
know contribute occasionally to at least one project of that size.

So *if* (and nobody knows but the meme is propagating out there) Darcs
is unsuitable for projects of that size, use of Darcs means that you
have to learn more than one tool, or not contribute to the popular
projects.

So my point is that the bottom line is there's work to be done before
pushing very hard on "consciousness-raising".  For example, update the
experience of the GHC project (which altogether is at the upper end of
the scale for "moderately large" proposed above).  The GHC wiki is
still downright scary about the quality of Darcs (you "can't" use
Darcs to get the trunk, it says).  There may be folks around who have
tried using Darcs 2 on Emacs repos.  If you can get some positive
testimonials from people working in that kind of project, then your "I
don't need scaling to super-huge" comment has a lot of force.  If not,
it sounds a lot like what the fox said about the grapes.

 > Worse, it is a collection of "brilliant speed hacks"

I'm not interested in defending git here, but that's just not true.
Git incorporates a number of important architectural features that
contribute to performance, which are shared by Mercurial and to some
extent Bazaar.  I don't know why git is less performant on Windows, or
likely to fail on Windows, but the contribution of the fundamental
design to its performance on POSIX systems shouldn't be denied.  It
makes you look like an anti-git agitator, not a Darcs advocate.

 > As a more-often-than-not Windows developer, it seems to me that
 > much of git's performance is at best inconsistent (contrary to git
 > fanatics'

But you should ignore the fanatics.  They aren't being listened to by
the audience you want to reach.  And you should be careful about
knocking git in public, or that audience won't listen to you, either. ;-)

I just don't see evidence here that Darcs is ready for a promotional
marketing campaign yet.  Work to confirm that it scales, testimonials
from more projects of at least the size of xmonad, and preferably an
order of magnitude larger.  Get any misimpressions on the GHC wiki
corrected.  Get GHC updated to Darcs 2 if they aren't already.  Those
efforts should come before a public campaign IMO.




More information about the darcs-users mailing list