On Fri, 07 Jul 2006, Madan S. wrote:
> 'svn merge' should not lose indirect merge information.
> (In branches/merge-tracking)
> * subversion/libsvn_client/diff.c:
> (do_merge): Obtain the latest mergeinfo on the target wc
> before merging and updating it with the current merge's info.
> Index: subversion/libsvn_client/diff.c
> --- subversion/libsvn_client/diff.c (revision 20465)
> +++ subversion/libsvn_client/diff.c (working copy)
> @@ -1931,6 +1931,11 @@
> SVN_ERR(reporter->finish_report(report_baton, pool));
> + /* Get the latest mergeinfo of the target_wcpath, before updating
> + it with the current merge's information */
> + SVN_ERR(parse_merge_info(&target_mergeinfo, target_wcpath, adm_access, ctx,
> + pool));
> if (!merge_b->dry_run && remaining_ranges->nelts > 0)
> SVN_ERR(update_wc_merge_info(target_wcpath, target_mergeinfo, rel_path,
> remaining_ranges, is_revert, adm_access,
After spending some time looking at this, it finally became apparent
that our previous incremental merges *may've changed the state* of the
WC's merge info. This *why* was not immediately obvious -- it
would've been very nice to have it described with the patch submission
(which did a good job of describing the *what*).
The WC's merge info only needs re-parsing if it also needs changing,
meaning that the call to parse_merge_info() moves down into the "if"
block shown above. This change also applies to do_single_file_merge();
I've committed it as r20515.
It would likely be more efficient if we could further conditionalize
re-parsing of the merge info based on whether any properties were
updated by the merge, or -- even better -- if the SVN_PROP_MERGE_INFO
property was updated. This might be able to be handled in conjunction
with the notification callback fixes.
Received on Mon Jul 10 22:42:02 2006
- application/pgp-signature attachment: stored