Philip Martin > "Bert Huijben" <[email protected]> writes: >>> + # The incoming "move" creates a tree-conflict as an incoming change >>> + # in a local move. We don't yet track moves on the server so we >>> + # don't recognise the incoming change as a move. >>> expected_output = svntest.wc.State(wc_dir, { >>> - 'A/B/E2/alpha' : Item(status='A '), >>> + 'A/B/E' : Item(status=' ', treeconflict='C'), >>> + 'A/B/E/alpha' : Item(status=' ', treeconflict='D'), >> >> treeconflict='D' ? >> >> I'm surprised that it works that way. > > The update produces the output: > > Updating 'svn-test-work/working_copies/update_tests-64': > C svn-test-work/working_copies/update_tests-64/A/B/E > D svn-test-work/working_copies/update_tests-64/A/B/E/alpha > A svn-test-work/working_copies/update_tests-64/A/B/F/alpha > Updated to revision 2. > Summary of conflicts: > Tree conflicts: 1 > > Do you think it should be something else?
I've never heard of us printing a 'D' in the tree conflict column, and the help for 'up' and 'merge' don't mention it where they describe this output, so yes it looks wrong or else is some bit of new design that hasn't been completed. - Julian
