On Thu, 15 Mar 2007, Paul Burba wrote:
> 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.
Paul's description of the merge info structures is accurate. What I
was suggesting was an occassional optimization, one that would add a
chunk of somewhat complicated code (a questionable trade-off). After
discussion on IRC, we decided to back-burner this one in favor of
working on functional issues.
- application/pgp-signature attachment: stored
Received on Tue Mar 20 22:00:02 2007