[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r26803 - in trunk/subversion: libsvn_client tests/cmdline

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: 2007-10-08 17:54:36 CEST

>> 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;
      /* 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*/

> 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.