On Wed, Nov 24, 2010 at 6:31 AM, 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.
>
I'm not sure I have a firm argument either way (yet). It is a little strange
that the same command would produce different results when done WC-to-WC vs
URL-to-*.
> > 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.
>
<snipped />
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
>
But merging the parent directories is a no-op, because the explicit merge
info on /branch stops r6 from being merged again.
> 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!
>
The mergeinfo (from the parent) is /trunk:6, which means that the changes
made to /trunk in r6 have already been merged into a parent. I guess it's
naive for SVN to work out that I'm trying to merge a change to a sub-tree of
/trunk to a sub-tree of /branches, when the same revision has been merged
into a parent. I guess it's because SVN only looks at the merge target
itself when determine the eligible revisions, rather than walking the tree
until it hits a node with explicit mergeinfo.
> 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.
>
Agreed. The case that I had came about due to a case-only rename, and
because we run windows, we did it via a URL (rather than an intermediate
commit). We'll know for next time. :-)
> 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.
>
Received on 2010-11-24 03:42:17 CET