On Fri, Nov 19, 2010 at 12:10 PM, Stefan Sperling <s...@elego.de> wrote: > On Fri, Nov 19, 2010 at 01:40:42PM +1000, Daniel Becroft wrote: >> On Tue, Nov 16, 2010 at 3:54 PM, Daniel Becroft <djcbecr...@gmail.com>wrote: >> >> > Hi, >> > >> > I've just found (another) issue with using URL-only renames. If one of the >> > parent directories has svn:mergeinfo recorded on it, then renaming a file >> > via a URL results in the new file containing a full copy of what was on the >> > trunk (but cut down to the individual file). >> > >> > Please see the following output from my test script (using SVN 1.6.13): >> > >> > >svn merge file:///D:/temp/svn_sandpit/repository/trunk . >> > --- Merging r4 through r5 into '.': >> > U A\alpha.txt >> > >> > >svn commit . --message "Merge r5 from trunk to branch." >> > Sending . >> > Sending A\alpha.txt >> > Transmitting file data . >> > Committed revision 6. >> > >> > >svn propget svn:mergeinfo >> > file:///D:/temp/svn_sandpit/repository/branches/branchA >> > /trunk:4-5 >> > >> > >svn propget svn:mergeinfo >> > file:///D:/temp/svn_sandpit/repository/branches/branchA/A/alpha.txt >> > >> > >svn rename >> > file:///D:/temp/svn_sandpit/repository/branches/branchA/A/alpha.txt >> > file:///D:/temp/svn_sandpit/repository/branches/branchA/A/beta.txt >> > --message >> > "Rename alpha.txt to beta.txt on branchA." >> > Committed revision 7. >> > >> > >svn propget svn:mergeinfo >> > file:///D:/temp/svn_sandpit/repository/branches/branchA/A/beta.txt >> > /trunk/A/alpha.txt:4-5 >> > >> > Notice that the 'svn propget' on alpha.txt indicates that there is no >> > svn:mergeinfo property available, but it gets added to beta.txt during the >> > rename. >> > >> > Is this intended behavior? > > I think the rationale for creating this mergeinfo is that Subversion cannot > tell whether you're creating a copy of something (which will not receive > merges directly) within a branch, or creating a subtree-branch (which will > directly receive merges). > > Consider a two-level branching scenario: > > A branch is created: > > svn cp ^/trunk/ ^/branches/mybranch > > This branch is synced to trunk periodically. > Then later someone decides to branch a subtree of this branch (this > is very different from branching the entire branch again!): > > svn cp ^/branches/mybranch/foo/bar ^/branches/mybranch/foo/bar-experimental > > The bar-experimental branch now inherits explicit mergeinfo from > the ^/branches/mybranches directory, say /trunk:40-50. > I suppose this is done to prevent further merges from trunk (or subtrees of > trunk) into bar-experimental from merging changes which have already been > merged into foo/bar (the ancestor branch of foo/bar-experimental).
I don't fully understand why this requires foo/bar-experimental to have its own explicit mergeinfo. If it wouldn't have explicit mergeinfo, wouldn't it just inherit mergeinfo from the branch root, like all subtrees of mybranch, hence knowing that /trunk:40-50 was already merged to it? 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? If it would be copied outside of mybranch, then yes, it would need explicit mergeinfo to remember what was already merged into it. Cheers, -- Johan