On Mon, Apr 19, 2010 at 10:35 AM, C. Michael Pilato <cmpil...@collab.net> wrote: > Paul Burba wrote: >> Anyhow, the test failed for Stefan because the --dry-run output was >> different: >> >> The dry-run merge output: >> --- Merging r5 through r9 into >> 'svn-test-work/working_copies/merge_tests-63.files': >> C svn-test-work/working_copies/merge_tests-63.files/B >> --- Merging r5 through r9 into >> 'svn-test-work/working_copies/merge_tests-63.files/mu': >> U svn-test-work/working_copies/merge_tests-63.files/mu >> --- Merging r5 through r9 into >> 'svn-test-work/working_copies/merge_tests-63.files': >> C svn-test-work/working_copies/merge_tests-63.files/D >> U svn-test-work/working_copies/merge_tests-63.files >> Summary of conflicts: >> Tree conflicts: 2 >> >> It's different yes, but merge_tests-63.files/mu, >> merge_tests-63.files/B, and merge_tests-63.files/D are just notified >> in a different order, there is nothing wrong with that that I can see, >> they are all at the same depth. > > What had me concerned about this output was the header lines: > > --- Merging r5 through r9 into > 'svn-test-work/working_copies/merge_tests-63.files': > --- Merging r5 through r9 into > 'svn-test-work/working_copies/merge_tests-63.files/mu': > --- Merging r5 through r9 into > 'svn-test-work/working_copies/merge_tests-63.files': > > "What? Merging r5-r9 to the root of the working copy twice?" > > But maybe I'm putting too much stock into what those headers are actually > saying about the real work going on underneath.
You are, that is what I was attempting to explain in my novella http://svn.haxx.se/dev/archive-2010-04/0435.shtml ;-) In particular, see the bit about "Multiple notification headers don't necessarily imply multiple editor drives" and also a little bit after that, the part about how notification headers are produced based on subtree mergeinfo. If you want to see this in action yourself with this very test, drop this snippet in at the start of merge.c:drive_merge_report_editor(): printf("\n================================================\n"); printf("drive_merge_report_editor\n"); printf("%...@%d\n", url1, revision1); printf("%...@%d\n", url2, revision2); printf("================================================\n"); And run the merge which causes Stefan's failure: merge_tests-62.files>svn merge ^^/A . -r4:9 ================================================ drive_merge_report_editor http://localhost/svn-test-work/repositories/merge_tests-62/a...@4 http://localhost/svn-test-work/repositories/merge_tests-62/a...@9 ================================================ --- Merging r5 through r9 into 'mu': U mu --- Merging r5 through r9 into '.': C D C B U . --- Recording mergeinfo for merge of r5 through r9 into '.': U . --- Recording mergeinfo for merge of r5 through r9 into 'mu': U mu Summary of conflicts: Tree conflicts: 2 Notice that the two notifications, "--- Merging r5 through r9 into 'mu':" and "--- Merging r5 through r9 into '.':" are both the result of the same editor drive. I'm open to suggestions on improving how the notification headers are produced, but there is only one editor drive happening here. As to Stefan's failure, his --dry-run notification order was B-mu-D, rather than mu-D-B. But all three are on the same depth within the target, so IIUC, there is no guarantee in the order in which they will be notified right? Paul
