> -----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.
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 20 07:33:46 2007