Re: URL-only renames adds svn:mergeinfo property

On Fri, Nov 19, 2010 at 12:10 PM, Stefan Sperling <stsp_at_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 <djcbecroft_at_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