Re: [merge-tracking]:

On Mon, 19 Mar 2007, Paul Burba wrote:

> > -----Original Message-----
> > From: Paul Burba [mailto:pburba@collab.net]
> > Sent: Thursday, March 15, 2007 1:19 PM
> > To: SVN Dev; Daniel Rall
> > Cc: Kamesh Jayachandran
> > Subject: [merge-tracking]:
> >
> > Yesterday on IRC:
> >
> > [14:19] dlr: pburba: Is there any particular reason that we call
> > svn_client__record_wc_merge_info() twice in update_wc_merge_info()?
> > [14:20] dlr: pburba: It seems like we could combine the
> > passed-in merge info with the "merges" parameter, then record
> > the merge info in the WC.
> > [14:21] dlr: Seems like that would be more efficient (though
> > possibly less safe?) [14:26] pburba: dlr: I tried that, but I
> > cant recall what the problem was, looking at it now it seems
> > you should be right. Let me look while I'm working on this
> > test failure - I'm already in the code
> >
> > (For those of you playing at home, the first call to
> > svn_client__record_wc_merge_info() I added in
> > update_wc_merge_info() was to ensure that inherited mergeinfo
> > on a merge target actually got set on that target.
> > Previously to r23785 is was not, see
> > http://subversion.tigris.org/issues/show_bug.cgi?id=2733 and
> > http://subversion.tigris.org/issues/show_bug.cgi?id=2734)
> >
> > ~~~~~
> >
> > Dan,
> >
> > The problem with combining the hashes MERGES with
> > TARGET_MERGEINFO is that the two hashes represent somewhat
> > different things in
> > update_wc_merge_info() and are used quite differently:
> >
> > TARGET_MERGEINFO - This is the explicit or inherited
> > mergeinfo on target_wcpath. I only call
> > svn_client__record_wc_merge_info() if the mergeinfo is
> > inherited, since that implies there is no mergeinfo on
> > target_wcpath (hmmm, not so sure about this now but let's go
> > with it for a minute*).
> >
> > MERGES - This hash is created by
> > determine_merges_performed() in
> > do_merge()/do_single_file_merge(). The paths in this hash
> > will always be within the adm_access we opened for this merge
> > using the merge target. This is important because
> > update_wc_merge_info() iterates over this hash and calls
> > svn_client__record_wc_merge_info() on the paths it pulls out
> > of MERGES. If we add the mergeinfo from TARGET_MERGEINFO
> > into MERGES, svn_client__record_wc_merge_info() would try to
> > set merge info on a path that is outside of the adm_access
> > and we'd get SVN_ERR_UNVERSIONED_RESOURCE.
> >
> > Does that all seem reasonable (excepting the following)?
> >
> >
> > * Yup, that assumption totally wrong, if discontinuous ranges
> > are merged on a target only the last range will get set on
> > the target as it is now
> > -- my patch dumbly resets the inherited mergeinfo on the
> > target each time update_wc_merge_info() is called.
>
> Fixed in r23917.

From the look of the patch, this discussion thread is dead (?).

> > I just added a new test to merge-tests to check for this and
> > am working on a fix right now. I know, I should have added
> > it to an existing test, but the obvious candidate is
> > local_mergeinfo_elision_and_inheritance,
> > but that is getting awfully long (and hard to follow) and is
> > currently Xfail. Maybe down the line I'll roll it into that
> > test, but for now I'd rather have it separate and know it's working.