[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: John <ansvnuser_at_gmail.com>
Date: Mon, 26 Mar 2012 15:15:17 -0500

On Mon, Mar 26, 2012 at 5:11 AM, Stefan Sperling <stsp_at_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_at_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_at_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_at_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_at_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_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.)

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?

John
Received on 2012-03-26 22:15:49 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.