On Wed, Nov 24, 2010 at 6:31 AM, Paul Burba <ptbu...@gmail.com> wrote:
> On Fri, Nov 19, 2010 at 12:25 PM, Stefan Sperling <s...@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. >
