>> Currently the notification happens from do_merge based on the
>> revisions we give from discover_and_merge_children. Actual
>> decision of which range to merge happens inside the
>> drive_merge_report_editor. If I move this logic to
>> discover_and_merge_children, we can fix the notification.
> Is it possible instead to move the logic determining the notification
> ranges from discover_and_merge_children() into
> drive_merge_report_editor()? Just thinking out loud...
Should be possible, but I am looking for strong reasons to do so.
> Let's for a moment say that all our notifications report we are merging
> into 'target' even though we may really be merging only into a subtree
> of target's (I don't think this is correct, but if I'm a lone voice in
> the wilderness on this I won't fight it).
As we *always* invoke a merge-report-editor on a target, notifications
are supposed to indicate same. May be from 'operative merge notification
receiver' we can indicate the rev ranges along with the path.
> Summing up, at present I see two problems:
> 1) We have inconsistent start range notifications, sometimes the
> notification range represents the acutal merge being performed,
> sometimes it does not. Not sure how to spin that as other than a flaw
'start range notifications always' = end_rev of last iteration.
<snip from discover_and_merge_children>
while (end_rev != SVN_INVALID_REVNUM)
/* Use persistent pool while playing with remaining_ranges. */
start_rev = end_rev;/*SEE HERE*/
> 2) Our notifications always show the merge target as the destination,
> even if the range in question is only being merged into one of the
> target's subtrees with differing mergeinfo. IMHO this is less serious,
> but does make for somewhat confusing outout.
See my answer above.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Oct 8 17:54:45 2007