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?
Received on 2013-02-04 20:02:41 CET