[darcs-users] darcs patch: make unit's return value depend on all tests

[Trent W. Buck]

Florent Becker <florent.becker at ens-lyon.org> writes:

>> Equally likely, they'd say "use Mercurial queues/Stacked Git/quilt".
>> IMO, that's the real competition for Darcs (in terms of patch theory;
>> for simply tracking history of a branch, Darcs's user interface is
>> still ahead of the competition, but git is catching up fast).
>
> I didn't know these, and after looking at it, i don't think they would
> have allowed me to do what i did: take an existing "blessed" history,
> and shuffle it "as much as possible while avoiding conflicts". But
> they sure look like patch theory under a disguise. The concept of
> "unapplied patch" in particular might be worth stealing.

My impression of hg queues is that they are an attempt to backport to hg
some of the most common use cases that Darcs supports, and that the
result is a *really* confusing mess, because it really doesn't fit the
underlying VCS.  I don't think I'm exaggerating when I say that hg
queues confused me as much as arch did.

Recently I heard about someone carrying a foot pump in their electric
car, in order to to charge the battery.  A bystander observed that what
he had was essentially an extremely heavy and inefficient bicycle.  That
is pretty much how I feel about hg queues.

PS: I use quilt sometimes for Debian patching, and for that it works
reasonably well (essentially, maintaining a tiny feature branch of some
upstream codebase, occasionally pulling everything from that codebase
and then resolving conflicts), but I think the main benefit of quilt
there is its VCS agnosticism (it works regardless of what upstream
uses), because Darcs would actually provide more flexibility there.