[darcs-users] Benchmarking "get"

Stephen J. Turnbull stephen at xemacs.org
Mon Mar 16 09:38:16 UTC 2009

Max Battcher writes:

 > I think we need to put together some good examples of:
 > 1. Here's a complicated changeset
 > 2. I've recorded it as darcs patches
 > 3. It takes 10 minutes to pull them from my branch x to joe random dev's 
 > branch y, ignoring upstream changes.
 > Versus:
 > 1. Here's a complicated changeset

The *same* complicated changeset, please.

 > Admittedly my example is contrived, but the point is that it matches 
 > what I've read in discussions

Of complex merges, which as has been pointed out here recently many,
perhaps most, Darcs users have learned to avoid.  And most of the
power of Darcs seems to be in the fact that "patches that touch
disjoint sets of files always commute".  But git handles such merges
effortlessly too, and blindingly quickly.

 > Right now there seems to be a consensus to instead meet the
 > complaints with an almost autonomic response "yes we have some
 > performance issues and we are working on them" and I don't think
 > that is quite doing us justice...

But pretending that Darcs workflows are handling problems of the
complexity of the Linux kernel workflow is not doing git justice,

I have a lot of sympathy for your arguments.  But while Ian & Co say
they *think* the exponential merge problem has been reduced to a
manageable level, nobody really knows.  And others say that while
Darcs 2 is better, they also know that their own workflows have
evolved to avoid conflicts.  Until you can demonstrate with actual
repos with equivalent DAGs that Darcs handles conflicts better than
git does, I for one am *personally*[1] going to stick with the speed
of git or Mercurial, and the flexibility of defining XEmacs commands
to handle complex procedures that I need to do repetitively (eg,
involving git-filter-branch), and for larger *cooperative projects*
I'm going to have a very difficult time championing Darcs if there are
enthusiastic proponents of git, hg, or even bzr around.

[1]  My personal projects are far less complex than what Darcs can
handle easily, sufficiently simple that I almost never run into hairy
conflicts when using git.  I mean, RCS would almost do....

More information about the darcs-users mailing list