[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] no mergeinfo on 'mergeinfo NON-affecting' wc-to-wc copy

From: Danil Shopyrin <danil_at_visualsvn.com>
Date: Tue, 16 Sep 2008 15:12:46 +0400

Here is the improved version of the original patch. Generally spoken,
the song remains the same. There are only following changes:
1) things become more optimized:
  a) we don't event call svn_client__get_wc_mergeinfo() for dst if src has
      explicit mergeinfo set on it
  b) we don't call svn_client__get_wc_mergeinfo() second time for src if it's
      a 'mergeinfo affecting' copy
2) there is one more test
3) propagate_mergeinfo_within_wc()'s logic modified more carefully. We
don't check for 'mergeinfo NON-affecting' copy for a locally
added/replaced PAIR->src without history.

The new log message is as follows:
Don't create any explicit (including empty) mergeinfo record during WC-to-WC
copy if it's a 'mergeinfo NON-affecting' copy. WC-to-WC copy can be
considered as 'megeinfo NON-affecting' if and only if the following
conditions are satisfied:
a) src and dst are located below the same URL
b) mergeinfo (if any) for src and dst is inherited from this URL
c) inherited mergeinfos (if any) for src and dst are equal.

* subversion/libsvn_client/copy.c
 (calculate_target_mergeinfo): svn_client__get_wc_mergeinfo() signature is
 (propagate_mergeinfo_within_wc): Heuristic algorihthm that checks is the copy
  operation 'mergeinfo affectiong' or not is added. Mergeinfo isn't propagated
  if it's 'mergeinfo NON-affecting' copy.

* subversion/libsvn_client/merge.c
  do_directory_merge): svn_client__get_wc_mergeinfo() signature is changed.

* subversion/libsvn_client/mergeinfo.c
 (svn_client__get_wc_mergeinfo): Signature is changed. Now returns
  effective_mergeinfo and effective_url and accepts additional
  allow_mixed_revisions flag.
  svn_client__elide_mergeinfo): svn_client__get_wc_mergeinfo() signature is

* subversion/libsvn_client/mergeinfo.h
 (svn_client__get_wc_mergeinfo): Signature is changed. Now returns
  effective_mergeinfo and effective_url and accepts additional
  allow_mixed_revisions flag.

* subversion/tests/cmdline/copy_tests.py
  copy_peg_rev_local_dirs): New copy behavior is considered: empty
  mergeinfo isn't generated during mergeinfo non-affecting copy.
  copy_src_explicit_mergeinfo): New tests.
 (branch_change_and_merge_back): Helper for the new tests.
 (test_list): Run the new tests.

The new patch is in the attachment.

On Wed, Sep 10, 2008 at 8:44 PM, Danil Shopyrin <danil_at_visualsvn.com> wrote:
>> Sure.  My point was that if check_mergeinfo_affecting() returns FALSE,
>> then we later redo some of the work that it does (like getting
>> mergeinfo for the source). I'd like to see the
>> avoid-setting-empty-mergeinfo logic merged into
>> propagate_mergeinfo_within_wc(), not kept separately.
> I can provide improved patch.
>>>> 1. Get the mergeinfo for the source.  If it's explicit, not inherited,
>>>> we're done, there's nothing to propagate, because the destination
>>>> already has the same explicit mergeinfo as the source, as a result of
>>>> the copy.  Currently, propagate_mergeinfo_within_wc() calls
>>>> calculate_target_mergeinfo(), we can replace this with a call to
>>>> svn_client__get_wc_mergeinfo().
>>> We don't need this step. This check is performed 'automatically'.
>>> Source and destination receive mergeinfo from different urls if the
>>> source have explicit mergeinfo.
>> You read both the source and the target's mergeinfo unconditionally.
>> If the source has explicit mergeinfo, you don't have to read the
>> destination's mergeinfo.
> I agree that logic can be optimized (it haven't done to keep the patch
> as simple as possible). I can improve the patch (especially if the
> whole concept will be approved :).
> --
> Danil
With best regards,
Danil Shopyrin
VisualSVN Team

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org

Received on 2008-09-16 13:13:08 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.