[darcs-users] Easily managing over 100, 000 lines of code with darcs

[Stephen J. Turnbull]

Simon Marlow writes:
 > On 31/03/10 17:20, Stephen J. Turnbull wrote:

 > > I'd need to know a lot more about the goals of the GHC workflow to
 > > improve accuracy, though.
 > 
 > That page isn't about GHC in particular, it's a general darcs-to-git 
 > conversion tutorial.

So?  My point is that there are a lot of ways to view that particular
comparison; I'd need to know the audience and/or the context pretty
well to choose one.

 > > I'd be interested to hear an explanation of the motivation of the
 > > workflow.
 > 
 > It's pretty simple: you have two branches.  One, the "head" is where you 
 > do all your development, and another, "stable" is one from which you are 
 > currently doing releases. Bug fixes are cherry-picked from head into 
 > stable regularly.  From time to time you fork head to make a new stable 
 > branch, and stop making releases from the old stable.
 > 
 > It's a very common development model, and the VCS should really
 > support it.

I think you are missing the difference between "lack of support" and
"different style of support".  I do that kind of cherrypicking with
git and Mercurial (substantially less convenient than git) all the
time.  The only thing I used to miss was the named patch thing which
made searching easier.  Now with gitk or hg view permanently plastered
on the screen, I don't even miss that.  Left click on the patch I
want, verify the patch is the right one in the patch view window, type
"git cherrypick ", middle click on the terminal window (selecting a
patch automatically sets the X selection to the SHA1 of the patch),
RET, and it's done.  The case where there are dependencies to worry
about are a small minority, and in git practice, they're often
collected in a rebase-able branch.

You don't have to like that workflow, not at all.  But I do, and
obviously I'm not alone.

 > > All of the major VCSes claim to support cherry-picking, and
 > > by their designers' lights I see no reason to think they don't do it
 > > well.
 > 
 > Right, well we all know how well darcs supports this model: very well 
 > (though not perfectly: sometimes I'd like to be able to cherry-pick 
 > patches without dependencies, but that's a separate discussion).

It's not a separate discussion, though; that's *why* I abandoned
serious use of Darcs in my main project of interest a few years ago.
Due to the way my codevelopers work, patch dependencies (and conflict
resolution) really got in my way.  If you don't want those, why use
Darcs?  (The answer was interactive patch assembly, but that wasn't
good enough. :-(  And then hg became the VCS-of-choice for Those-Who-
Did-The-Work of migrating from CVS, so....)

My whole point here is that people keep talking about how wonderful
Darcs is and why doesn't everybody else understand that?  Why are the
same old false criticisms leveled at Darcs over and over again?  In
both cases, the reason is that it all depends on context, especially
workflows.  Darcs is highly tuned to the workflow you personally
happen to like, but that workflow doesn't work for me.  Darcs has some
unique workflows like "spontaneous branching", but that one probably
won't work well in my context because of large branches landing
frequently compared to my own rate of contribution.  Darcs is poorly
tuned to workflows that I do like and/or are well-matched to the
project workflow.

 > [In a git cherrypick w]hat you get is a different patch - the
 > information that you cherry-picked the original patch has been
 > discarded.

Not always, not entirely, but even when present it's not used for
much, that's true.

 > I believe git is clever enough to avoid conflicts if you later
 > re-merge the branch, or cherry pick other patches,

Yes and no.  It does have such algorithms, and since cherry-picks
don't pull along dependencies cherry-picking different patches won't
introduce new conflict, but the real saving grace is git's *humility*.
git deliberately provides low-level commands from which a Sufficiently
Smart User can cobble together a safety net, eg, git rerere ("reuse
recorded resolution").  Of course Sufficiently Smart Users are rare
(even users who are sufficiently smart often prefer not to spend time
on such things), but they leave their tools on the workbench and other
users pick them up and refine them.

Darcs, on the other hand, has Patch Theory and tries to solve
everything with Patch Theory.  This leads to a much smoother
experience in many workflows (and has the occasional pleasing surprise
like "spontaneous branching"), but if you run into a stopper, you
often don't really have any alternative short of brute force: applying
patches by hand, or reinitializing the branch.

 > but I think the algorithms are based on heuristics (i.e. a
 > super-clever do-what-I-wanted merge) rather than precise patch
 > commutation as in darcs, so the algorihtms will fail when things
 > get complex.

That's the theory, but I submit that (1) Darcs does not really have a
precise patch theory because it's all founded on the heuristic
"textual conflict == patch conflict" (with heuristic exceptions), and
(2) the git way obviously works really well in practice for lots of
people.  I don't think that the pragmatic comparison is at all clear.