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

Re: Sparse working copy in 1.8.0 causes problems for others' merges; 1.7.x didn't complain

From: Paul Burba <ptburba_at_gmail.com>
Date: Wed, 15 May 2013 19:46:36 -0400

On Wed, May 15, 2013 at 1:06 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Mon, May 13, 2013 at 9:58 PM, Bob Cardillo <bob.cardillo_at_gmail.com> wrote:
>> I'm running Subversion 1.8.0-dev on Windows 7 Pro SP1.
>>
>> The following steps went through without error on 1.7.x, but they fail with
>> an error on the last step when run on 1.8.0 (see below for full reproducible
>> recipe):
>
> Hi Bob,
>
> Thanks for the detailed script. Comments follow inline.
>
>> 1. make a copy (branch) of your trunk
>> 2. Harry checks out the branch in full
>> 3. Sally sparsely checks out the branch with just a subset of subtrees
>> 4. someone adds something in trunk under one of the subtrees that Sally has
>> excluded
>> 5. someone removes something from trunk under the subtree added in step 4
>> 6. Sally merges trunk into the branch (remember she has the sparse working
>> copy)
>> 7. Harry merges trunk into the branch
>> BAM! Harry can't commit the merge because:
>> svn: E155011: Commit failed (details follow):
>> svn: E155011: Directory 'C:\testbranch1_userX\B\B1\B1a' is out of date
>> svn: E160028: '/branches/branch1/B/B1/B1a' is out of date
>>
>> I suspect this has something to do with one or both of these two issues,
>> completed in 1.8.0:
>> - http://subversion.tigris.org/issues/show_bug.cgi?id=4305
>> - http://subversion.tigris.org/issues/show_bug.cgi?id=4169
>>
>> Can someone confirm?
>>
>> Is this a new bug introduced in 1.8.0 or a correction of an oversight in
>> 1.7.x? Either way, what is the workaround? It seems to me that a merge into
>> a sparse working copy either shouldn't be allowed,
>
> Merges into sparse working copies, while not encouraged, should work.
> It's one of the reasons we have non-inheritable mergeinfo. Here's a
> brief explanation before we dive into the bug in the final merge.
>
> Right before r6, Sally has this shallow WC:
>
> C:\SVN\sandbox\shallow-merge-targets-1.7\testbranch1_userY>svn st -v
> 2 2 pburba . <--Depth=empty
> 2 1 pburba C <-- Depth=infinity
>
> The merge adds some new subtrees in the children that are present
> (i.e. C). Changes that affect the missing subtree 'B' are skipped:
>
> C:\SVN\sandbox\shallow-merge-targets-1.7\testbranch1_userY>svn merge ^^/trunk
> Skipped 'B'
> --- Merging r2 through r5 into 'C':
> A C\C1
> A C\C1\test.txt
> --- Recording mergeinfo for merge of r2 through r5 into '.':
> U .
> --- Recording mergeinfo for merge of r2 through r5 into 'C':
> U C
> Summary of conflicts:
> Skipped paths: 1
>
> Mergeinfo describing the merge is as expected. Non-inheritable
> mergeinfo is set on the target, which indicates that any missing
> children (e.g. 'B') didn't get those changes. 'C' get's it's own full
> set of (normal inheritable) mergeinfo describing the change.
>
> C:\SVN\sandbox\shallow-merge-targets-1.7\testbranch1_userY>svn pl -vR
> Properties on '.':
> svn:mergeinfo
> /trunk:2-5*
> Properties on 'C':
> svn:mergeinfo
> /trunk/C:2-5
>
> This is all expected and by design. Do note that with 1.8, this
> missing paths affected under 'B' do get a special conflict
> notification:
>
> C:\SVN\sandbox\shallow-merge-targets\testbranch1_userY>svn merge ^^/trunk
> --- Merging r2 through r5 into '.':
> Skipped missing target: 'B'
> A B\B1\test.txt <- A'dd' in the fourth column let's users know
> what was skipped under a missing subtree.
> A B\B1 <-- Ditto
> A C\C1
> A C\C1\test.txt
> --- Recording mergeinfo for merge of r2 through r5 into '.':
> U .
> --- Recording mergeinfo for merge of r2 through r5 into 'C':
> U C
> Summary of conflicts:
> Skipped paths: 1
>
> C:\SVN\sandbox\shallow-merge-targets\testbranch1_userY>svn st
> M .
> M C
> A + C\C1
>
> C:\SVN\sandbox\shallow-merge-targets\testbranch1_userY>svn pl -vR
> Properties on '.':
> svn:mergeinfo
> /trunk:2-5*
> Properties on 'C':
> svn:mergeinfo
> /trunk/C:2-5
>
>> or it should work
>> correctly. In other words, this recipe should either fail on step 6 above
>> (instead of 7) or it should go all the way through correctly, including step
>> 7.
>
> So yes, that final merge by Harry into a infinite depth WC should work
> like it does in 1.7. I'll try to figure out what is wrong here.

Haven't been able to figure out what the problem is. I filed an issue
to track this: http://subversion.tigris.org/issues/show_bug.cgi?id=4367

See also http://subversion.tigris.org/issues/show_bug.cgi?id=4367#desc2
which describes what appears to be a somewhat simpler manifestation of
the same problem. Added a new regression test in
http://svn.apache.org/viewvc?view=revision&revision=1483125

> --
> Paul T. Burba
> CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
> Skype: ptburba

--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Received on 2013-05-16 01:47:08 CEST

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