RE: Problem with merge notifications?

>> Or, since the second merge is into D, why don't we say as
>> much as part of the merge notification (especially when
>> A_COPY already contains those revs)?

>Kamesh and I had discussed this a little here: http://svn.haxx.se/dev/archive-2007-10/0274.shtml (I was >too quick to wave the white flag on this.)

>Anyway, I agree that is misleading, but what if the second merge of r4-r5 affected multiple subtrees? >Say 'A_COPY\B\E' also had differing mergeinfo from the target, would we list all the notifications first?

>--- Merging r4 through r5 into 'merge_tests-1\A_COPY\D':
>--- Merging r4 through r5 into 'merge_tests-1\A_COPY\B\E':
>U merge_tests-1\A_COPY\D\G\rho
>U merge_tests-1\A_COPY\B\E\beta

>Nah, that misleading (though I think simpler to do with the current code), we'd want something like this:

>--- Merging r4 through r5 into 'merge_tests-1\A_COPY\D':
>U merge_tests-1\A_COPY\D\G\rho
>--- Merging r4 through r5 into 'merge_tests-1\A_COPY\B\E':
>U merge_tests-1\A_COPY\B\E\beta

>But with the given post-26803 implementation I'm not sure how easy this is, Kamesh, thoughts?

--- Merging r4 through r5 into 'merge_tests-1\A_COPY\B\E': <---This line comes prior to finish report
U merge_tests-1\A_COPY\B\E\beta <--This line comes from notification call back.

To produce this kind of output I think we should move code that prints '--- Merging r4 through r5 into 'merge_tests-1\A_COPY\B\E':' 'notification callback'.

I am more concerned about the simplicity of this new implementation. Let me see.

With regards
Kamesh Jayachandran
Received on Tue Oct 9 21:55:22 2007