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.
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.
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).
Cheers, Ganesh _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
