> -----Original Message-----
> From: Kamesh Jayachandran
> Sent: Monday, October 08, 2007 11:55 AM
> To: Paul Burba
> Cc: dev@subversion.tigris.org; Lieven Govaerts
> Subject: Re: svn commit: r26803 - in trunk/subversion:
> libsvn_client tests/cmdline
>
>
> > 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.
I understand that, I only meant that sometimes the call to
drive_merge_report_editor() is going to affect a given subtree that has
differing mergeinfo from the target. Anyhow, I withdraw this objection.
> > 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*/
Yes, I understand where the current code makes this determination - see
my patch in http://svn.haxx.se/dev/archive-2007-10/0216.shtml.
What I am asking is 'why?'. Wait! Don't answer that! :-) Let's back
off from the implementation details for now. I'll start a new thread
describing the notification behavior that I see as somewhat problematic.
If I'm the only one who thinks so we can let this die.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 8 20:24:50 2007