[darcs-users] rolling back/unpulling a patch with dependencies

[David Roundy]

On Sat, Apr 17, 2004 at 09:20:25PM +0100, Ganesh Sittampalam wrote:
> I have a repository with patches A and B (simplifying somewhat). Patch B
> seems to depend on patch A because they touch close-by things, but for no
> essential reason. I'd really like to push *just* patch B to another
> repository; I'll happily clean up any conflicts that result from this
> afterwards.
> 
> However, I can't just push patch B, and none of the tools
> (unpull/rollback) lets me undo patch A in any way [in a staging
> repository]. Am I missing something obvious? Can I remove the dependency
> somehow?

Alas, there isn't any way to get around this.  :( Other than simply
unrecording and then re-recording the patch.  The fundamental problem is
that darcs takes dependencies seriously, and that in this case the
dependency isn't "real".

> If solving this isn't possible by design, it seems to me like a major
> failing of darcs; being able to do just this kind of selective work with
> patches is one of the main things that attracted me to it. I could undo
> this particular patch manually, since it's small, but that's not really
> the point, since next time it might be rather bigger.

This is definitely something I'd like to be able to do.  I have some ideas
on the subject (which I came up with when thinking about merges), which I
think will work, but are definitely a job for post-darcs-1.0, since they
require major changes throughout darcs.

Basically, the idea is to make all patches commute, with the proviso that
some commutations produce conflicts.  This moves the complexity of the
current merge process into the commute function.  One advantage this has is
that the commute function is much simpler in terms of the constraints
placed upon it--for example the result of two commutes must always give you
the same pair of patches back again.  There are other more subtle issues
that this approach could also fix.  But of course, this new idea (which I'm
increasingly favoring) will need a lot of work to make sure that it
actually works.

Interestingly, I hadn't considered its application to the problem you're
describing until just now.  As a caveat, when I've worked out how the
commutation needs to behave (when commuting can produce a conflict), it may
be that I'll find that this method will produce undesirable side-effects.
For example, it's hard to see how to deal with the conflict produced when
commuting a file modification with the creation of that file.
-- 
David Roundy
http://www.abridgegame.org