On Mon, Apr 19, 2010 at 10:35 AM, C. Michael Pilato <cmpilato_at_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("%s@%d\n", url1, revision1);
printf("%s@%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
Received on 2010-04-19 18:33:12 CEST