[darcs-users] *practical* differences between darcs' patch model and git/mercurial's?

[Adam Megacz]

Matt Palmer <mpalmer at hezmatt.org> writes:
> Cherry picking.  Darcs' cherry picking abilities are fantastic, while every
> other system (and I've tried most of 'em by now) seems to have at least one
> big inhibitor to cherry picking.  For the way I work on the systems I work
> on, good cherry picking is a must.

My experience with cherry-picking in darcs is that it works nicely,
but usually drags in a huge quantity of patches that it feels the
cherry-picked patch "depends" on (the "depends" appears to be
calculated very, very conservatively).

Aside from not needing to generate merger-patches, is this any
different from mercurial/git?  In those systems, if you're willing to
drag in the entire history leading up to the chosen patch and generate
a merger, is there ever a problem with cherry-picking?

> I've seen instructions in projects' development guides to avoid merging when
> it's not absolutely necessary to avoid polluting the change history with
> merges.  A revision control system that makes its users avoid merges seems a
> bit suboptimal to me.

Yes, I agree.  My only gripe is that cherry picking seems to trigger
darcs' bad time-complexity behaviors, so it has become "good darcs
practice" to not use the one feature that distinguishes it from other
systems.

Or maybe I'm just cranky from having lost nearly every "what revision
control should we use?" debate lately.

  - a

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380