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

Re: URL-only renames adds svn:mergeinfo property

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Tue, 23 Nov 2010 22:36:53 +0100

On Tue, Nov 23, 2010 at 9:31 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Fri, Nov 19, 2010 at 12:25 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> Hi All,
> The short story, the following behaviors are intentional:
> A) WC-to-WC [copies | moves]: Destination only gets explicit mergeinfo
> if the source has it.
> B) URL-to-[WC | URL] [copies | moves]: Destination gets explicit
> mergeinfo if the source has it.  If the source doesn't have explicit
> mergeinfo, but inherits it, then that inherited mergeinfo is made
> explicit on the destination.
> The slightly longer story...
> As Stefan already mentioned, in 1.5.0-1.5.4 'A' behaved like 'B'.
> When we changed the WC-to-WC behavior in 1.5.5, we purposefully didn't
> change the URL-to-* behavior.  But honestly, this was probably as much
> out of caution as for any other reason, since there are use cases
> where 'B' helps you even when doing copies within the same branch (see
> my example that follows).
> If someone wants to make the argument on the dev list that 'A' should
> be the default behavior for all copies and moves, I for one am quite
> willing to listen and probably assist, and maybe do all the coding
> (which should be pretty minimal), but this isn't on my personal TODO
> list at the moment.
>> On Fri, Nov 19, 2010 at 12:38:57PM +0100, Johan Corveleyn wrote:
>>> I don't see why it matters that it's a "sub-branch". It's still a
>>> (grand-)child of mybranch, so can perfectly inherit that mergeinfo.
>>> AFAIU it only needs explicit mergeinfo if it starts to deviate from
>>> the mybranch root (e.g. if something is (sync-)merged directly to the
>>> sub-branch). Or am I missing something?
>> Hmmm.. I don't see any reason either. Explicit mergeinfo could probably be
>> created later when the subtree actually becomes a merge target.
>> I guess the current logic in the code simply doesn't account for the case
>> where the copy destination is a child of the source? Not sure.
> The basic problem with not making a copy* source's inherited mergeinfo
> explicit on the destination is that a bit of merge history can get
> lost.  Here is a simple example of this:
> Say we have a simple two branch (trunk and branch) repos like this:
> ---trunk_at_1---r6-------@6------------------------->
>      |     text      |
>     copy   change   sync
>      |      to      merge
>      |    D/H/psi    |
>      |               |
>      V               V
>    branch_at_2----------r7----------r9-------r10--->
>                               WC-to-WC    identical text
>                               copy of     changes to
>                              D/H/psi to   D/H/psi-WC
>                              D/H/psi-WC   and
>                                 and       D/H/psi-URL
>                               URL-to-WC
>                               copy of
>                              D/H/psi to
>                              D/H/psi-URL
> The merge in r7 leaves this mergeinfo on the root of the branch:
>  >svn pl -vR
>  Properties on 'branch':
>    svn:mergeinfo
>      /trunk:2-6
> Nothing unusual there.  The WC-to-WC copy made in r9 creates no new
> mergeinfo, but the URL-to-WC copy does create mergeinfo on psi-URL:
>  >svn pl -vR
>  Properties on 'branch':
>    svn:mergeinfo
>      /trunk:2-6
>  Properties on 'branch\D\H\psi-URL':
>    svn:mergeinfo
>      /trunk/D/H/psi:2-6
> This is exactly the behavior Daniel initially reported.
> Note that r10 makes some changes to psi-URL and psi-WC that conflicts
> with the changes made in r6.  What happens if we attempt to re-merge
> r6 directly to psi-WC or psi-URL?
> In the case of psi-URL, nothing happens, the merge is a no-op:
>  >svn merge ^/A/D/H/psi branch\D\H\psi-URL -c6
>  >svn st
>  >
> Nor should anything happen, since the merge source, ^/A/D/H/psi_at_6, is
> already part of the target's merge history (per its explicit
> mergeinfo).
> Now let's try the same merge, but targeting psi-WC.  We know from the
> preceding diagram that psi-WC's merge history should be semantically
> equivalent to psi-URL's and we *should* get a no-op, but instead...
>  >svn merge ^/trunk/D/H/psi branch\D\H\psi-WC -c6
>  Conflict discovered in 'branch/D/H/psi-WC'.
>  Select: (p) postpone, (df) diff-full, (e) edit,
>          (mc) mine-conflict, (tc) theirs-conflict,
>          (s) show all options: p
>  --- Merging r6 into 'branch\D\H\psi-WC':
>  C    branch\D\H\psi-WC
>  Summary of conflicts:
>    Text conflicts: 1
> Why did this happen?  Because psi-WC's actual merge history (i.e. its
> natural history and explicit/implicit mergeinfo) doesn't include
> '/trunk/D/H/psi:6'.
> Now you may be thinking, "but doesn't it inherit that history from the
> root of branch?".  Unfortunately it doesn't, it does inherit mergeinfo
> from branch, but it inherits '/trunk/D/H/psi-WC:6', which is obviously
> not what we are merging and has the added distinction of not even
> existing in the repository**
> This is because mergeinfo inheritance is a simple path-wise
> calculation: A path without mergeinfo inherits the mergeinfo of its
> nearest parent with explicit mergeinfo, with all the merge source
> paths adjusted by the path difference between the path and its parent.
>  Yes, I'd love to come up with a more concise way to explain that!
> Anyhow, that is where not recording the source's inherited mergeinfo
> on the copy destination can bite us.  Is is a big problem?  Not sure,
> but the workaround to avoid it, using WC-to-WC copies, doesn't seem
> that draconian.  If you agree or not, I'm more than happy to kick
> around improvements on the dev list.
> Thanks,
> Paul
> * I talk about copies here, but the same issues apply to moves.
> ** In 1.7 I made improvements so that such bogus inherited mergeinfo
> doesn't get recorded, see
> http://subversion.tigris.org/issues/show_bug.cgi?id=3669, but in
> 1.5-1.6 we have that added insult.

Thanks a lot for the explanation, Paul. Very interesting.

I didn't realize that merge tracking currently does not "follow"
copies/moves (and that this explicit mergeinfo on URL-to-[WC|URL]
copies is a way to implement this). I can envision a future where
merge tracking will become more powerful to handle this without
explicit mergeinfo (calculating correctly inherited mergeinfo through
copies/renames), especially if svn ever wants to be able to handle
merges through renames.

But I fully appreciate that these things take time to be developed,
and the current solution works reasonably well. Now that I understand
this, I see that this explicit mergeinfo in behavior B is not a
problem, and in fact more correct than leaving it out in behavior A.

Maybe I'll continue discussion on the dev-list, but currently lack the
cycles a little bit. Anyway, thanks for the background info.


Received on 2010-11-23 22:37:53 CET

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

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