[darcs-devel] splitting and merging patches

David Leuschner david.leuschner at gmail.com
Fri Mar 15 22:24:35 UTC 2013


Hi Ganesh

thank's for thinking this all through!

> So...on to the alternative :-)
>
> Rebase does let you do pretty much the same thing, but with the
> important caveat that the identity of W will change in the process. So
> the original repo had X and W, and the new repo will have XA, XB and W',
> where W' has the same changes and the same visible commit message as W
> (unless you deliberately change anything), but will be treated by darcs
> as a different patch.

And that's the problem and the reason why I'm looking for a different
split.  For use rebase leads to an unacceptable solution because W
change to W' (and fortunately with duplicates there's a way to replace
X with some X' without changing W.  Here's the real world use case:

We've got an advanced repository setup: we're developing an iOS client
and a Haskell server that are communicating via Google Protocol
Buffers.  We don't want to have client and server in one source
repository because they're unrelated (server only works on Linux,
client only builds on Mac) and we don't want client developers to
worry or see server patches (that's just a usability issue: I'd
constantly see patches I have no interest in) and the other way
around.  But we want to share the protocol buffer definitions and we
only want one patch.  We've decided to create one Darcs repository
containing three independent sets of patches: client, server and
protocols.  We've got a branch containing only client and protocol
patches and we've got a branch containing only server and protocols
patches. This works really good.  There's one caveat: no patch
touching protocols may ever depend on a patch from client or server
because then we wouldn't be able to keep client and server separate
but share the protocols.

In August 2011 I've made such a patch and because it was a very large
and disruptive server change that was amend-recorded many times it
went through our review unnoticed until some weeks ago when a client
developer changed a protocol-definition that could not be applied in
the server branch because it had conflicts with the unnoticed one-line
change of the same protocol definition.  Actually there shouldn't be a
conflict because my stupid protocol-change was unnecessary and
irrelevant and could just have been reverted or unpulled - but it's
not a single patch as it should have been.  It's included in the large
disruptive change nearly all following patches depend on.  There's no
way we can change this patch W to W' because everybody would have to
stop working on changes and switch to a rebased version of the
repository containing W'.  That's too expensive to do in a team setup.

Fortunately there's a way around that: my patch can be split into the
large disruptive part and the unnecessary protocol change and with
duplicate-magic I can pull in both versions, swap them, pull in all
the hundreds of patches that depend on the disruptive change and some
time later unpull the bad version of my large patch.  We did that
trick several times but it's still time consuming (but only for one
team member and not for the whole team).

This may happen more often to us than to others because of our special
repository structure that only works if dependencies are right.  We've
also got some very strict additional policies regarding patch naming
and "no conflicts". All "official" branches may never contain
conflicting patches.  We've used Darcs 1 a long time and are very
happy how good everything works if conflicts only happen in private
user repositories and conflicts are solved by amend-recording and
sequencing patches.

So please keep the "duplicates"-feature - we might not be using Darcs
anymore if this feature wouldn't work so good for us.

Cheers,

     David


More information about the darcs-devel mailing list