On Mon, Feb 04, 2013 at 05:23:52PM +0000, Philip Martin wrote: > The test reaches a state with a delete-edit tree-conflict on X/B/C as a > result of the update following some of the moves. This conflict has to > be resolved to state 'working' which will remove the tree-conflict on > X/B/C and raise a move-edit tree-conflict on X/B/C/D/E. Resolving that > new move-edit tree-conflict to state 'mine-conflict' will update E2 and > allow the test to pass. However when the resolver is invoked on X/B/C > it automatically proceeds to resolve the new tree-conflict on X/B/C/D/E > and that causes the test to fail. > > Having the resolver raise new tree-conflicts is new behaviour. Having > the resolver code use the status walker is also new behaviour. To make > this work I need the resolver to avoid resolving the newly raised > tree-conflict but I'm not sure how best to do this. Sometimes resolving > newly raised tree-conflicts is helpful to the user.
As far as I can see the only problem here is that you'd like to resolve the conflict on 'X/B/C' to 'choose merged', but because the test ends up passing depth infinity to svn_wc__resolve_conflicts() it also resolves 'X/B/C/D/E' to 'choose_merged', while you want to resolve that node to 'mine_conflict' instead. I haven't tried, but you could probably change the test to pass a depth != infinity to svn_wc__resolve_conflicts() when resolving on 'X/B/C'. Would that help?
