You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by a nsvnuser <an...@gmail.com> on 2012/03/23 22:26:07 UTC
Unexpected behavior during mergeinfo elision scenario
I have a mergeinfo elision scenario that is behaving in a manner
I do not understand.
I have a clean checkout of a branch (to eliminate any
mixed revision working copy behavior):
$ svn co [URL redacted]/myproject/branches/X
$ cd X
The difference in the mergeinfo, between subdir and subdir/A,
is revision 1489-2779 (inclusive)
$ svn pg 'svn:mergeinfo' subdir
/myproject/branches/W/subdir:1488-2675
/myproject/branches/Y/subdir:5925-7118
/myproject/trunk/subdir:2780-7532
$
$ svn pg 'svn:mergeinfo' subdir/A
/myproject/branches/W/subdir/A:1488-2675
/myproject/branches/Y/subdir/A:5925-7118
/myproject/trunk/subdir/A:1489-7532
The only difference in the merge info is "subdir/A" contains
the merge range between 1489 and 2779 (inclusive), where "subdir"
does not contain that same merge range.
So, based on the information at this url:
http://www.collab.net/community/subversion/articles/merge-info.html
...I would expect that merging revisions 1489-2779 (inclusive)
into "subdir", would cause the mergeinfo on "subdir/A" to elide.
This does not appear to be the case.
In fact, the merge changed nothing.
svn merge -r 1488:2779 ^/myproject/trunk/subdir subdir
--- Recording mergeinfo for merge of r1489 through r2675 into 'subdir':
U subdir
svn diff
[No output]
Perhaps this behavior is somehow related
to natural history / implicit mergeinfo?
In revision 1488
^/myproject/branches/W was created
via a copy from ^/myproject/trunk@1487
In revision 2768
^/myproject/branches/X was created via
a copy from ^/myproject/trunk@1487
In revision 2780
^/myproject/trunk was replaced via
a copy from ^/myproject/branches/W@2675
svn --version
svn, version 1.7.3 (r1242825)
svnserve --version
svnserve, version 1.7.3 (r1242825)
Any clarification would be greatly appreciated!
Thanks,
John
Re: Unexpected behavior during mergeinfo elision scenario
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Mar 26, 2012 at 03:15:17PM -0500, John wrote:
> $ svn merge --record-only ^/myproject/trunk/subdir@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@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.
Re: Unexpected behavior during mergeinfo elision scenario
Posted by John <an...@gmail.com>.
On Mon, Mar 26, 2012 at 5:11 AM, Stefan Sperling <st...@elego.de> wrote:
> On Fri, Mar 23, 2012 at 04:26:07PM -0500, a nsvnuser wrote:
>> svn merge -r 1488:2779 ^/myproject/trunk/subdir subdir
>> --- Recording mergeinfo for merge of r1489 through r2675 into 'subdir':
>> U subdir
>>
>> svn diff
>> [No output]
>
>> In revision 2780
>> ^/myproject/trunk was replaced via
>> a copy from ^/myproject/branches/W@2675
>
> So the history of trunk traces back into the W branch in some range
> that ends with r2779.
>
> To merge from the pre-replace 'trunk/subdir' object you need to specify a
> peg revision that tells svn to look for 'trunk/subdir' in a version of
> the versioned tree in which the path 'trunk/subdir' still corresponds to
> the pre-replace object. Else you're merging from a different line of
> history than you intend to merge from.
>
> Try this: svn merge -r 1488:2779 ^/myproject/trunk/subdir@2779 subdir
>
> An analogy would be that you tell me to fetch an item ("change" in svn's
> terms) from an office ("path" in svn's terms) located in an office building
> ("repository") that contains an office on each floor ("revision").
> But you don't specify which floor I am supposed to go look for the item.
> Saying just "the office" without specifying a floor is ambiguous.
> So I might come back empty-handed because I went to the wrong floor.
>
> See also http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html
Ah, thank you! I had experimented a little with pegging the revisions
but apparently didn't have it quite right at the time.
^/myproject/trunk was deleted at revision 2779, so an attempt
to merge in the suggested manner fails:
svn merge -r 1488:2779 ^/myproject/trunk/subdir@2779 subdir
svn: E160013: '.../rvr/2779/myproject/trunk/subdir' path not found
I was able to get the elision to occur with two merges
by pegging the revision,
by not including the "-r" flag,
and by including the "--record-only" flag:
e.g.
$ svn merge --record-only ^/myproject/trunk/subdir@2780 subdir
$ svn pg 'svn:mergeinfo' subdir
subdir - /myproject/branches/W/subdir:1488-2675
/myproject/branches/Y/subdir:5925-7118
/myproject/trunk/subdir:2676-7532
$ svn pg 'svn:mergeinfo' subdir/A
subdir/A - /myproject/branches/W/subdir/A:1488-2675
/myproject/branches/Y/subdir/A:5925-7118
/myproject/trunk/subdir/A:1489-7532
$ svn merge --record-only ^/myproject/trunk/subdir@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.)
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@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?
John
Re: Unexpected behavior during mergeinfo elision scenario
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Mar 23, 2012 at 04:26:07PM -0500, a nsvnuser wrote:
> svn merge -r 1488:2779 ^/myproject/trunk/subdir subdir
> --- Recording mergeinfo for merge of r1489 through r2675 into 'subdir':
> U subdir
>
> svn diff
> [No output]
> In revision 2780
> ^/myproject/trunk was replaced via
> a copy from ^/myproject/branches/W@2675
So the history of trunk traces back into the W branch in some range
that ends with r2779.
To merge from the pre-replace 'trunk/subdir' object you need to specify a
peg revision that tells svn to look for 'trunk/subdir' in a version of
the versioned tree in which the path 'trunk/subdir' still corresponds to
the pre-replace object. Else you're merging from a different line of
history than you intend to merge from.
Try this: svn merge -r 1488:2779 ^/myproject/trunk/subdir@2779 subdir
An analogy would be that you tell me to fetch an item ("change" in svn's
terms) from an office ("path" in svn's terms) located in an office building
("repository") that contains an office on each floor ("revision").
But you don't specify which floor I am supposed to go look for the item.
Saying just "the office" without specifying a floor is ambiguous.
So I might come back empty-handed because I went to the wrong floor.
See also http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html