>> 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)
{
svn_revnum_t next_end_rev;
svn_pool_clear(iterpool);
/* Use persistent pool while playing with remaining_ranges. */
slice_remaining_ranges(children_with_mergeinfo, is_rollback,
end_rev, pool);
..........................
start_rev = end_rev;/*SEE HERE*/
</snip>
> 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.
>
> Paul
>
See my answer above.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 8 17:54:45 2007