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

Re: Unexpected behavior during mergeinfo elision scenario

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 27 Mar 2012 10:44:14 +0200

On Mon, Mar 26, 2012 at 03:15:17PM -0500, John wrote:
> $ svn merge --record-only ^/myproject/trunk/subdir_at_2676 subdir
>
> $ svn pg 'svn:mergeinfo' subdir
> subdir - /myproject/branches/W/subdir:1488-2675
> /myproject/branches/Y/subdir:5925-7118
> /myproject/trunk/subdir:1488-7532
>
> $ svn pg 'svn:mergeinfo' subdir/A
> (At this point the merginfo on subdir/A has been elided.)

Great!

> I'm now seeing the desired elision behavior, but I do not fully understand
> why using "--record-only" changed the behavior so dramatically.
> Without the "--record-only" flag, nothing was modified.
> e.g.
> $ svn merge -q ^/myproject/trunk/subdir_at_2780 subdir
> $ svn diff
> [no output from svn diff]
>
> Shouldn't the changes to "svn:mergeinfo" be the same,
> regardless of whether or not "--record-only" is used?

I think this happens because there are no operative revisions
for 'subdir' in the range being merged. As of the 1.7 release,
Subversion no longer creates mergeinfo changes for unaffected
subtrees during merges.
See http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording

However, this behaviour wasn't implemented for record-only merges.
Record-only merges still update all subtree mergeinfo within the
merge target. I don't know why record-only merges behave differently.
Perhaps the new behaviour is too difficult to implement for record-only
merges, or maybe this difference exists on purpose.
Received on 2012-03-27 10:45:02 CEST

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.