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

[David Roundy]

On Sun, Apr 18, 2004 at 01:51:36PM +0100, Ganesh Sittampalam wrote:
> On Sun, 18 Apr 2004, David Roundy wrote:
> 
> > > 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.
> 
> You mean patch B? That didn't actually occur to me, but since there are
> actually several patch Bs that'd be impractical.

Yeah, that's what you'd have to do.  Since it is patch B that depends on
patch A, patch B needs to be rerecorded if you want to remove that
dependency.

> > 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.
> 
> I've been trying to get my head round precisely what merging is lately,
> and still haven't quite managed it, which is perhaps an indication that
> it's the wrong primitive [or of course that my brain doesn't work like
> yours, or indeed at all!] For me, I think universal commutation is easier
> to comprehend.

Of course, it could just be that the documentation of merging is really
bad...

> > 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.
> 
> My initial thought would be to treat that as a conflict for the directory
> the file was in, and just dump a file with some special name and those
> contents into the directory. Then the user can put the contents into
> whatever file they want to resolve the contents.

What you're suggesting is a means of resolving or marking the conflict, but
that is a totally separate issue.  In commutation, special file names
should be avoided (since there is no way to know if a file of that name
already exists), but in the resolution of a conflict, they're all
right--since the resolution doesn't need to be uniquely defined, a unique
special filename can be chosen.
-- 
David Roundy
http://www.abridgegame.org