[darcs-devel] Re: [darcs-conflicts] bit more of a summary of new conflict-handling ideas

[David Roundy]

On Thu, Jul 13, 2006 at 02:45:40PM +0100, Ganesh Sittampalam wrote:
> On Thu, 13 Jul 2006, David Roundy wrote:
> [identical patches conflicting or not]
> >But it's not a conflict, that's the point.
> 
> If it is a conflict, then we can easily resolve it and push the resolution 
> to everyone else.
> 
> If it isn't a conflict, then we're in trouble if we wanted it to be one, 
> because we can't turn it into one after the fact.

No, if it isn't a conflict, there's no difference, except that
*everyone* won't be forced to deal with the issue.

The one person who has darcs warn him about changes which are members
of more than one patch will notice and push a fix (in the relatively
rare case that it is necesary) to everyone else, just like any other
bug in the code.

> >We can't have it both ways.  Either identical primitive patches 
> >conflict, or they don't. Neither choice is optimal in all cases, but we 
> >have to make a choice. I think since either is reasonable, we can go 
> >with what's convenient, and with this approach, I think we're much 
> >better off in terms of the danger of escalating conflict wars (i.e. 
> >conflict resolutions that conflict), which can be a real problem when 
> >you've got N developers all pulling from one another.
> 
> Your new approach to resolutions probably makes it very easy to add a 
> resolution type that means "accept both these identical patches", which 
> would solve this problem, though I haven't worked this out for sure.

That's precisely the problem I'm talking about.  If two people use
this resolution that indicates "accept both these identical patches",
then there's a conflict between their two identical resolutions saying
to resolve those previous identical patches.

> Another possibility would be to make it a property of the primitive patch 
> whether it could be silently merged with an identical primitive patch. 
> This is probably less elegant and more burdensome on the UI, though. 
> (Probably the default behaviour should be controlled a pullable repo 
> property like setpref boringfile).

Definitely not.  Way too cumbersome, for no benefit that I can
discern.
-- 
David Roundy