Re: [darcs-devel] Re: Example Conflicts
On Fri, Aug 03, 2007 at 01:54:14PM +0100, Ian Lynagh wrote: > On Fri, Aug 03, 2007 at 05:04:59AM -0700, Jason Dagit wrote: > > On 8/3/07, Simon Marlow <[EMAIL PROTECTED]> wrote: > > > David Roundy wrote: > > > > On Wed, Aug 01, 2007 at 01:58:29AM +0100, Ian Lynagh wrote: > > > > > > >> And the "cancel A" patch doesn't have any sort of reference to B in it? > > > > > > > > Right. > > > > > > I seem to remember there was a problem with this approach. Perhaps not a > > > technical problem, but a conceptual one. > > > > > > Something like this: > > > > > > Suppose patches A and B conflict, and David and Ian both have repositories > > > containing A and B. > > > > > > Ian resolves in favour of A, records cancel(B). > > > David resolves in favour of B, records cancel(A). > > > > > > Ian pulls from David, and now has both cancel(A) and cancel(B). At this > > > point we expect a conflict, because both David and Ian have resolved the > > > original conflict in different ways; but cancel(A) and cancel(B) commute. > > > Don't they? > > > > Wouldn't we expect both A and B to be canceled instead of a conflict? > > These are two conflicting resolutions of the A+B conflict, so logically > they ought to conflict. In your proposal /conflicts between two patches/ > aren't actually resolved though, you just /cancel individual patches/ > until all the conflicts are gone, so in your world you do just get A and > B both being cancelled. > > Making the resolutions conflict requires a more complex system, and what > you are proposing is almost on the way to the more complex system (I > think), so is probably worth implementing first regardless. Actually, (see response to Simon) I don't think making resolutions conflict is actually any more complex... except for requiring the addition of activation patches, which is conceptually simple, and can be done without change of conflict semantics. > My biggest concern, for both systems, is the UI. I'm pretty sure that something on the lines of a "revert" UI should work adequately, which asks users which conflicting changes they don't want (or alternatively, do want, and cancel the rest), but leaves the "war paint" in the working directory. Certainly we could do better than this, but I think this is a good start. And actually, a UI option that simply cancels *all* conflicting changes might even be adequate. I don't think that'd be any more confusing than our existing semantics--which admittedly confuse users, but define a baseline that users are capable of handling, except when it fails entirely. -- David Roundy Department of Physics Oregon State University ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] Re: Example Conflicts
On Fri, Aug 03, 2007 at 11:08:07AM +0100, Simon Marlow wrote: > David Roundy wrote: > >On Wed, Aug 01, 2007 at 01:58:29AM +0100, Ian Lynagh wrote: > > >>And the "cancel A" patch doesn't have any sort of reference to B in it? > > > >Right. > > I seem to remember there was a problem with this approach. Perhaps not a > technical problem, but a conceptual one. > > Something like this: > > Suppose patches A and B conflict, and David and Ian both have repositories > containing A and B. > > Ian resolves in favour of A, records cancel(B). > David resolves in favour of B, records cancel(A). > > Ian pulls from David, and now has both cancel(A) and cancel(B). At this > point we expect a conflict, because both David and Ian have resolved the > original conflict in different ways; but cancel(A) and cancel(B) commute. > Don't they? That is correct, and it's an infelicity of the proposed system. I believe it's unlikely to be a major problem, because in practice most resolutions (I think) will not only cancel one patch, but also make some other changes to incorporate both "ideas," and this patch will depend on one of the two patchs A or B. The problem arises when the two patches really both did the same thing, so cancelling either of them is by itself an adequate resolution. This infelicity can be avoided by adding an activation patch in the process of resolving. This patch type (which has been implemented in an earlier bit of Jason's work) is an identity patch that depends on a particular patch. So if Ian resolves in favour of A, records cancel(B) activate(A). David resolves in favour of B, records cancel(A) activate(B). then we'd get the whole conflict reappearing when our two resolutions are merged, which is what you (and I) want. We have the option (as a resolution UI choice separate from the choice of "conflict" semantics) of adding this behavior by default at a later date, so we've not painted ourselves into a corner here (so far as I can tell). An activation patch is a "normal" patch, in the sense that it's an ordinary primitive patch with no special semantics. You might consider its commutation behavior special, but of course every patch has commutation behavior unique to that patch type, so there's nothing "unique" about this... -- David Roundy Department of Physics Oregon State University ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] Re: Example Conflicts
On Fri, Aug 03, 2007 at 05:04:59AM -0700, Jason Dagit wrote: > On 8/3/07, Simon Marlow <[EMAIL PROTECTED]> wrote: > > David Roundy wrote: > > > On Wed, Aug 01, 2007 at 01:58:29AM +0100, Ian Lynagh wrote: > > > > >> And the "cancel A" patch doesn't have any sort of reference to B in it? > > > > > > Right. > > > > I seem to remember there was a problem with this approach. Perhaps not a > > technical problem, but a conceptual one. > > > > Something like this: > > > > Suppose patches A and B conflict, and David and Ian both have repositories > > containing A and B. > > > > Ian resolves in favour of A, records cancel(B). > > David resolves in favour of B, records cancel(A). > > > > Ian pulls from David, and now has both cancel(A) and cancel(B). At this > > point we expect a conflict, because both David and Ian have resolved the > > original conflict in different ways; but cancel(A) and cancel(B) commute. > > Don't they? > > Wouldn't we expect both A and B to be canceled instead of a conflict? These are two conflicting resolutions of the A+B conflict, so logically they ought to conflict. In your proposal /conflicts between two patches/ aren't actually resolved though, you just /cancel individual patches/ until all the conflicts are gone, so in your world you do just get A and B both being cancelled. Making the resolutions conflict requires a more complex system, and what you are proposing is almost on the way to the more complex system (I think), so is probably worth implementing first regardless. My biggest concern, for both systems, is the UI. Thanks Ian ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
[darcs-devel] Re: Example Conflicts
On 8/3/07, Simon Marlow <[EMAIL PROTECTED]> wrote: > David Roundy wrote: > > On Wed, Aug 01, 2007 at 01:58:29AM +0100, Ian Lynagh wrote: > > >> And the "cancel A" patch doesn't have any sort of reference to B in it? > > > > Right. > > I seem to remember there was a problem with this approach. Perhaps not a > technical problem, but a conceptual one. > > Something like this: > > Suppose patches A and B conflict, and David and Ian both have repositories > containing A and B. > > Ian resolves in favour of A, records cancel(B). > David resolves in favour of B, records cancel(A). > > Ian pulls from David, and now has both cancel(A) and cancel(B). At this > point we expect a conflict, because both David and Ian have resolved the > original conflict in different ways; but cancel(A) and cancel(B) commute. > Don't they? Wouldn't we expect both A and B to be canceled instead of a conflict? Perhaps we should consider this a conflict of interest, but it's not clear to me that it should be a patch/change conflict. Maybe Ian or David has a thought. And yes, cancel(A) and cancel(B) commute as cancellations are designed to always commute. thanks, Jason ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
[darcs-devel] Re: Example Conflicts
David Roundy wrote: On Wed, Aug 01, 2007 at 01:58:29AM +0100, Ian Lynagh wrote: And the "cancel A" patch doesn't have any sort of reference to B in it? Right. I seem to remember there was a problem with this approach. Perhaps not a technical problem, but a conceptual one. Something like this: Suppose patches A and B conflict, and David and Ian both have repositories containing A and B. Ian resolves in favour of A, records cancel(B). David resolves in favour of B, records cancel(A). Ian pulls from David, and now has both cancel(A) and cancel(B). At this point we expect a conflict, because both David and Ian have resolved the original conflict in different ways; but cancel(A) and cancel(B) commute. Don't they? Cheers, Simon ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
