On 31/03/10 17:20, Stephen J. Turnbull wrote:
Simon Marlow writes:
> I didn't write that page, but just wanted to point out that it's a wiki
> - please feel free to edit the page to be more accurate/honest as
> appropriate.
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.
> In response to your last point though, I'd counter that darcs supports
> the cherry-picking workflow that we use in GHC, whereas none of the
> other VCs do (or at least, they don't support it well).
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.
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. I can easily imagine that many who like git would dislike Darcs
and vice-versa, and that it would depend a lot on what you mean by
"support 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
the default way of working in darcs; I don't have to use any special
commands, I just push and pull patches to achieve this workflow.
In the other VCSs, the cherry-picking commands amount to extracting a
diff of the cherry-picked patch and applying it to the branch, with the
same log message. What you get is a different patch - the information
that you cherry-picked the original patch has been discarded. I believe
git is clever enough to avoid conflicts if you later re-merge the
branch, or cherry pick other patches, 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. I've seen cases where git's attempts to
automatically figure out when a file was renamed go wrong, and it's
highly confusing.
Also, there's no automatic derivation of patch dependencies, so if you
want to cherry-pick a patch with dependencies you have to figure out the
dependencies manually.
Cheers,
Simon
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
