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

Re: Mergeinfo overwritten from successive merges

From: Branko Čibej <brane_at_wandisco.com>
Date: Fri, 14 Mar 2014 06:30:07 +0100

Over on users@, we got a report about mergeinfo being overwritten when
two different merges to the same branch were made from different working
copies. I've been able to reproduce this with the attached script; but
only via http://, local:// and svn:// refuse to commit the second merge,
as expected.

Another data point: this can only be reproduced when 'trunk' and
'branch' are not related; if I create 'branch' as a copy of 'trunk',
this does not happen.

The Apache config I used was a simple

LoadModule dav_svn_module /usr/local/opt/subversion/libexec/mod_dav_svn.so
<Location /repro/repo>
  DAV svn
  SVNPath /tmp/test/repo
  Order allow,deny
  Allow from all
</Location>

Here's the output of my script:

brane_at_zulu:/tmp/test$ ~/repro2.sh
+ svnadmin create repo
+ svn checkout http://localhost/repro/repo structure
Checked out revision 0.
+ svn mkdir structure/trunk
A structure/trunk
+ svn mkdir structure/branch
A structure/branch
+ svn commit -mm structure
Adding structure/branch
Adding structure/trunk

Committed revision 1.
+ echo aa
+ svn add structure/trunk/a
A structure/trunk/a
+ svn commit -mm structure
Adding structure/trunk/a
Transmitting file data .
Committed revision 2.
+ echo bb
+ svn add structure/trunk/b
A structure/trunk/b
+ svn commit -mm structure
Adding structure/trunk/b
Transmitting file data .
Committed revision 3.
+ svn checkout http://localhost/repro/repo/branch user1
Checked out revision 3.
+ svn checkout http://localhost/repro/repo/branch user2
Checked out revision 3.
+ svn merge -c2 http://localhost/repro/repo/trunk user1
--- Merging r2 into 'user1':
A user1/a
--- Recording mergeinfo for merge of r2 into 'user1':
 U user1
+ svn commit -mm user1
Sending user1
Adding user1/a

Committed revision 4.
+ svn proplist -v http://localhost/repro/repo/branch
Properties on 'http://localhost/repro/repo/branch':
  svn:mergeinfo
    /trunk:2
+ svn merge -c3 http://localhost/repro/repo/trunk user2
--- Merging r3 into 'user2':
A user2/b
--- Recording mergeinfo for merge of r3 into 'user2':
 U user2
+ svn commit -mm user2
Sending user2
Adding user2/b

Committed revision 5.
+ svn proplist -v http://localhost/repro/repo/branch
Properties on 'http://localhost/repro/repo/branch':
  svn:mergeinfo
    /trunk:3

-- Brane

On 14.03.2014 06:21, Branko Čibej wrote:
> On 14.03.2014 02:18, Jeb Wilson wrote:
>>
>> Hello,
>>
>>
>>
>> I’ve reproduced this mergeinfo overwriting issue using the following
>> steps. We are seeing this with svn client v1.8.8, and using a remote
>> VisualSVN server v2.7.0 (which uses svn v1.8.8). NOTE: This cannot be
>> replicated by using a locally created repo…we’ve only been able to
>> replicate with VisualSVN remotely.
>>
>>
>>
>> TO REPRODUCE:
>>
>> We started out by creating an empty repo called TestRepo on the
>> server. Then:
>>
>>
>>
>> E:\Colspace\sandbox2>mkdir fullrepo
>>
>>
>>
>> E:\Colspace\sandbox2>svn checkout
>> https://svn.colspace.com/svn/TestRepo fullrepo
>>
>>
>>
>> Checked out revision 0.
>>
>>
>>
>> E:\Colspace\sandbox2>cd fullrepo
>>
>>
>>
>> E:\Colspace\sandbox2\fullrepo>svn mkdir trunk
>>
>> A trunk
>>
>>
>>
>> E:\Colspace\sandbox2\fullrepo>svn mkdir branch
>>
>> A branch
>>
>
> I can reproduce this, using http:// and the exact structure you're
> using -- i.e., when 'trunk' and 'branch' are not related, as in your
> case. When they are related (that is, 'branch' is a copy of 'trunk'),
> the commit after the second merge fails, as expected.
>
> I'm not entirely sure if this is expected behaviour or not, but I
> suspect it isn't. Can you please report an issue?
>
> -- Brane
>
>
> --
> Branko Čibej | Director of Subversion
> WANdisco // Non-Stop Data
> e. brane_at_wandisco.com

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com

Received on 2014-03-14 06:31:25 CET

This is an archived mail posted to the Subversion Dev mailing list.