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.
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.
Paul B.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 15 18:18:44 2007