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
