On Wed, May 01, 2013 at 08:32:55PM +0100, Julian Foad wrote: > r1477876, which I proposed for back-port to 1.8.x, fills in the 'node kind' > field correctly for a prop conflict. The code in 'svn' shown below now leads > to a crash because the 'file/edit/edit' case matches a prop conflict and > calls the text conflict handler function, which asserts that the conflict > kind is 'text'. > > Stefan Sperling, can you confirm the intention there was to match only a text > conflict? (I think this is your code.)
I don't think I wrote this code originally but I certainly touched it during the 1.8-dev timeframe. Your patch looks very sensible to me. > This looks like a simple enough fix (shown below), except I'm dealing with > a knock-on effect already so I thought > it's time I posted here to get a second opinion. I'm a bit uncertain about > the 'obstruction' handling below it. How do the obstruction cases relate to > the conflict kinds 'text', 'prop', and 'tree'? The obstruction handling dates back to 1.5, I believe. It was added as part of the original conflict resolution callback implementation. > If there are any obstruction cases that are reported as conflict kind 'text', > then this patch would probably break them. I don't know if there are. > That wouldn't make any sense anyway. They should be tree-conflicts.
