You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bob Cardillo <bo...@gmail.com> on 2013/05/14 03:58:03 UTC
Sparse working copy in 1.8.0 causes problems for others' merges;
1.7.x didn't complain
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):
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, 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.
Here's the complete recipe for Windows (it creates the repository from
scratch, so the only assumption is that you have a C: drive):
cd /d C:\
svnadmin create test_repo
svn checkout file:///C:/test_repo svntestrepo
cd svntestrepo
md trunk
cd trunk
md B
md C
cd ..
md branches
svn add branches
svn add trunk
svn commit -m ""
svn copy "^/trunk" "^/branches/branch1" -m ""
svn checkout "^/branches/branch1" ..\testbranch1_userX
svn checkout --depth empty "^/branches/branch1" ..\testbranch1_userY
cd ..\testbranch1_userY
svn update --set-depth infinity C
svn checkout "^/trunk" ..\testtrunk
cd ..\testtrunk\B
md B1
cd B1
echo B1 test > test.txt
md B1a
cd B1a
echo B1a test > test.txt
cd ..\..
svn add B1
cd ..
svn commit -m ""
cd C
md C1
cd C1
echo C1 test > test.txt
cd ..
svn add C1
cd ..
svn commit -m ""
cd B\B1
svn delete B1a
cd ..\..
svn commit -m ""
cd ..\testbranch1_userY
svn merge "^/trunk"
svn commit -m ""
cd ..\testbranch1_userX
svn update
svn merge "^/trunk"
svn commit -m ""
Thanks!
Re: Sparse working copy in 1.8.0 causes problems for others' merges;
1.7.x didn't complain
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 05/13/2013 09:58 PM, Bob Cardillo 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):
> 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?
I can confirm this same behavior on Linux.
If I change the final commit into an 'svn st -v' instead, I see this for 1.7
clients:
M 6 6 cmpilato .
6 1 cmpilato B
A + - 3 ? B/B1
D + - ? ? B/B1/B1a
D + - ? ? B/B1/B1a/test.txt
+ - 3 cmpilato B/B1/test.txt
6 6 cmpilato C
6 6 cmpilato C/C1
6 4 cmpilato C/C1/test.txt
And this for 1.8.0 clients:
M 6 6 cmpilato .
6 1 cmpilato B
A + - 3 cmpilato B/B1
D + - ? ? B/B1/B1a
A + - 3 cmpilato B/B1/test.txt
6 6 cmpilato C
6 6 cmpilato C/C1
6 4 cmpilato C/C1/test.txt
I've attached my Unix-ized version of your recipe script in case someone
else wants to take a look-see.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Sparse working copy in 1.8.0 causes problems for others' merges;
1.7.x didn't complain
Posted by Paul Burba <pt...@gmail.com>.
On Thu, May 16, 2013 at 11:07 AM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Paul Burba [mailto:ptburba@gmail.com]
>> Sent: donderdag 16 mei 2013 16:10
>> To: Bert Huijben
>> Cc: Bob Cardillo; dev
>> Subject: Re: Sparse working copy in 1.8.0 causes problems for others'
>> merges; 1.7.x didn't complain
>>
>> On Thu, May 16, 2013 at 3:59 AM, Bert Huijben <be...@qqmail.nl> wrote:
>> >
>> >> -----Original Message-----
>> >> From: Paul Burba [mailto:ptburba@gmail.com]
>> >> Sent: donderdag 16 mei 2013 01:47
>> >> To: Bob Cardillo
>> >> Cc: dev
>> >> Subject: Re: Sparse working copy in 1.8.0 causes problems for others'
>> >> merges; 1.7.x didn't complain
>> >>
>> >> On Wed, May 15, 2013 at 1:06 PM, Paul Burba <pt...@gmail.com>
>> wrote:
>> >> > On Mon, May 13, 2013 at 9:58 PM, Bob Cardillo
>> <bo...@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
>> >
>> > I haven't looked at the specific details yet, but a specific behavior change
>> between <= 1.7 and 1.8 is that Subversion 1.8 now compares the incoming
>> delete with the local version of all nodes. (A TODO item since Subversion 1.6)
>>
>> Hi Bert,
>>
>> Is there an issue associated with this? Or could you just point me to
>> a particular revision(s)?
>>
>> > If the incoming delete describes the delete of something else that what is
>> available locally then the node is marked as tree conflicted.
>> >
>> > One very common case that this helps for is when nodes are moved. If a
>> directory tree was changed before it was moved, then Subversion <= 1.7
>> would just delete the old tree and insert a copy of whatever is merged in. -->
>> You would lose track of the changes in the original location.
>> >
>> > I don't think this comparison code was really tested with sparse trees in
>> mind. (We usually don't write detailed tests of cases we don't support)
>>
>> I'm confused...we don't support sparse working copies anymore? Also,
>> to be clear, the problem doesn't appear to be with merges to shallow
>> WCs. That seems to work as it did in 1.7. The problem occurs when
>> merging to a uniform revision WC at infinite depth.
>
> I think we still do, but how can we determine if an incoming 'delete <this-exact-tree>' should apply to a node that is not there?
>
> In 1.6 and 1.7 we just deleted every directory tree, without verifying anything (and for files we did a limited check). This was a MAJOR todo left in our tree conflict implementation.
>
> Even in a shallow working copy scenario, the delete of exactly what is not there is an unlikely operation: usually you would merges that apply to your tree.. Not merges that delete exactly what is not in your tree.
>
> So if you commit you delete everything, and the mergetracking won't help you in any way as we can't store mergeinfo on a deleted node.
>
>
> I would say that noting that you do something dangerous like this would be a good reason to give a tree conflict. The user can then decide: "yes this is what I intended to do", or "no, I shouldn't have applied this merge".
>
> Maybe there is some middle ground where a few levels of directories apply to your working copy, and some deeper subdirectory is sparse. In this case I can see why you would want to apply the delete without further verifications... But in other cases I don't think you want that to be the default behavior.
Don't become fixated on the mention of shallow WCs. They are not the
problem here.
Please look at both Bob's reproduction script and the test I added for
issue #4367 (merge_tests.py 139: repeat merge to infinite depth WC
conflicts) because there is *no* problem with the merge to the shallow
WC! His problem is a merge to an infinite depth working copy (which
succeeds but cannot be committed). Similarly, with merge test #139,
the merge to the shallow WC works as expected, it's the merge to an
infinite depth WC that fails.
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Re: Sparse working copy in 1.8.0 causes problems for others' merges;
1.7.x didn't complain
Posted by Paul Burba <pt...@gmail.com>.
On Thu, May 16, 2013 at 11:14 AM, Bert Huijben <be...@qqmail.nl> wrote:
>
>> -----Original Message-----
>> From: Bert Huijben [mailto:bert@qqmail.nl]
>> Sent: donderdag 16 mei 2013 17:07
>> To: 'Paul Burba'
>> Cc: 'Bob Cardillo'; 'dev'
>> Subject: RE: Sparse working copy in 1.8.0 causes problems for others'
>> merges; 1.7.x didn't complain
>>
>>
>>
>> > -----Original Message-----
>> > From: Paul Burba [mailto:ptburba@gmail.com]
>> > Sent: donderdag 16 mei 2013 16:10
>> > To: Bert Huijben
>> > Cc: Bob Cardillo; dev
>> > Subject: Re: Sparse working copy in 1.8.0 causes problems for others'
>> > merges; 1.7.x didn't complain
>> >
>> > On Thu, May 16, 2013 at 3:59 AM, Bert Huijben <be...@qqmail.nl> wrote:
>> > >
>> > >> -----Original Message-----
>> > >> From: Paul Burba [mailto:ptburba@gmail.com]
>> > >> Sent: donderdag 16 mei 2013 01:47
>> > >> To: Bob Cardillo
>> > >> Cc: dev
>> > >> Subject: Re: Sparse working copy in 1.8.0 causes problems for others'
>> > >> merges; 1.7.x didn't complain
>> > >>
>> > >> On Wed, May 15, 2013 at 1:06 PM, Paul Burba <pt...@gmail.com>
>> > wrote:
>> > >> > On Mon, May 13, 2013 at 9:58 PM, Bob Cardillo
>> > <bo...@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
>> > >
>> > > I haven't looked at the specific details yet, but a specific behavior change
>> > between <= 1.7 and 1.8 is that Subversion 1.8 now compares the incoming
>> > delete with the local version of all nodes. (A TODO item since Subversion
>> 1.6)
>> >
>> > Hi Bert,
>> >
>> > Is there an issue associated with this? Or could you just point me to
>> > a particular revision(s)?
>> >
>> > > If the incoming delete describes the delete of something else that what is
>> > available locally then the node is marked as tree conflicted.
>> > >
>> > > One very common case that this helps for is when nodes are moved. If a
>> > directory tree was changed before it was moved, then Subversion <= 1.7
>> > would just delete the old tree and insert a copy of whatever is merged in. -
>> ->
>> > You would lose track of the changes in the original location.
>> > >
>> > > I don't think this comparison code was really tested with sparse trees in
>> > mind. (We usually don't write detailed tests of cases we don't support)
>> >
>> > I'm confused...we don't support sparse working copies anymore? Also,
>> > to be clear, the problem doesn't appear to be with merges to shallow
>> > WCs. That seems to work as it did in 1.7. The problem occurs when
>> > merging to a uniform revision WC at infinite depth.
>>
>> I think we still do, but how can we determine if an incoming 'delete <this-
>> exact-tree>' should apply to a node that is not there?
>>
>> In 1.6 and 1.7 we just deleted every directory tree, without verifying
>> anything (and for files we did a limited check). This was a MAJOR todo left in
>> our tree conflict implementation.
>>
>> Even in a shallow working copy scenario, the delete of exactly what is not
>> there is an unlikely operation: usually you would merges that apply to your
>> tree.. Not merges that delete exactly what is not in your tree.
>>
>> So if you commit you delete everything, and the mergetracking won't help
>> you in any way as we can't store mergeinfo on a deleted node.
>>
>>
>> I would say that noting that you do something dangerous like this would be a
>> good reason to give a tree conflict. The user can then decide: "yes this is
>> what I intended to do", or "no, I shouldn't have applied this merge".
>>
>> Maybe there is some middle ground where a few levels of directories apply
>> to your working copy, and some deeper subdirectory is sparse. In this case I
>> can see why you would want to apply the delete without further
>> verifications... But in other cases I don't think you want that to be the default
>> behavior.
>
> I think the primary issue is
> http://subversion.tigris.org/issues/show_bug.cgi?id=3210
> Issue#3210 "Merge should raise a tree-conflict when deleting a modified"
I traced the test failure in the test I added (merge_tests.py 139:
repeat merge to infinite depth WC conflicts) to r1443112, which were
fixes for issue #2282 and issue #3150. Bob's scenario however, still
fails, so my initial suspicion that
http://subversion.tigris.org/issues/show_bug.cgi?id=4367#desc2
described the same problem he saw was incorrect. There are two
different problems.
> But it goes back to the design of tree conflicts: when to raise delete tree conflicts.
> (use case 5)
>
> The design says that we should raise a tree conflict when what is to be deleted is not an exact match to what exists locally.
>
> Bert
>
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
RE: Sparse working copy in 1.8.0 causes problems for others' merges; 1.7.x didn't complain
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Bert Huijben [mailto:bert@qqmail.nl]
> Sent: donderdag 16 mei 2013 17:07
> To: 'Paul Burba'
> Cc: 'Bob Cardillo'; 'dev'
> Subject: RE: Sparse working copy in 1.8.0 causes problems for others'
> merges; 1.7.x didn't complain
>
>
>
> > -----Original Message-----
> > From: Paul Burba [mailto:ptburba@gmail.com]
> > Sent: donderdag 16 mei 2013 16:10
> > To: Bert Huijben
> > Cc: Bob Cardillo; dev
> > Subject: Re: Sparse working copy in 1.8.0 causes problems for others'
> > merges; 1.7.x didn't complain
> >
> > On Thu, May 16, 2013 at 3:59 AM, Bert Huijben <be...@qqmail.nl> wrote:
> > >
> > >> -----Original Message-----
> > >> From: Paul Burba [mailto:ptburba@gmail.com]
> > >> Sent: donderdag 16 mei 2013 01:47
> > >> To: Bob Cardillo
> > >> Cc: dev
> > >> Subject: Re: Sparse working copy in 1.8.0 causes problems for others'
> > >> merges; 1.7.x didn't complain
> > >>
> > >> On Wed, May 15, 2013 at 1:06 PM, Paul Burba <pt...@gmail.com>
> > wrote:
> > >> > On Mon, May 13, 2013 at 9:58 PM, Bob Cardillo
> > <bo...@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
> > >
> > > I haven't looked at the specific details yet, but a specific behavior change
> > between <= 1.7 and 1.8 is that Subversion 1.8 now compares the incoming
> > delete with the local version of all nodes. (A TODO item since Subversion
> 1.6)
> >
> > Hi Bert,
> >
> > Is there an issue associated with this? Or could you just point me to
> > a particular revision(s)?
> >
> > > If the incoming delete describes the delete of something else that what is
> > available locally then the node is marked as tree conflicted.
> > >
> > > One very common case that this helps for is when nodes are moved. If a
> > directory tree was changed before it was moved, then Subversion <= 1.7
> > would just delete the old tree and insert a copy of whatever is merged in. -
> ->
> > You would lose track of the changes in the original location.
> > >
> > > I don't think this comparison code was really tested with sparse trees in
> > mind. (We usually don't write detailed tests of cases we don't support)
> >
> > I'm confused...we don't support sparse working copies anymore? Also,
> > to be clear, the problem doesn't appear to be with merges to shallow
> > WCs. That seems to work as it did in 1.7. The problem occurs when
> > merging to a uniform revision WC at infinite depth.
>
> I think we still do, but how can we determine if an incoming 'delete <this-
> exact-tree>' should apply to a node that is not there?
>
> In 1.6 and 1.7 we just deleted every directory tree, without verifying
> anything (and for files we did a limited check). This was a MAJOR todo left in
> our tree conflict implementation.
>
> Even in a shallow working copy scenario, the delete of exactly what is not
> there is an unlikely operation: usually you would merges that apply to your
> tree.. Not merges that delete exactly what is not in your tree.
>
> So if you commit you delete everything, and the mergetracking won't help
> you in any way as we can't store mergeinfo on a deleted node.
>
>
> I would say that noting that you do something dangerous like this would be a
> good reason to give a tree conflict. The user can then decide: "yes this is
> what I intended to do", or "no, I shouldn't have applied this merge".
>
> Maybe there is some middle ground where a few levels of directories apply
> to your working copy, and some deeper subdirectory is sparse. In this case I
> can see why you would want to apply the delete without further
> verifications... But in other cases I don't think you want that to be the default
> behavior.
I think the primary issue is
http://subversion.tigris.org/issues/show_bug.cgi?id=3210
Issue#3210 "Merge should raise a tree-conflict when deleting a modified"
But it goes back to the design of tree conflicts: when to raise delete tree conflicts.
(use case 5)
The design says that we should raise a tree conflict when what is to be deleted is not an exact match to what exists locally.
Bert
Re: Sparse working copy in 1.8.0 causes problems for others' merges;
1.7.x didn't complain
Posted by Paul Burba <pt...@gmail.com>.
On Thu, May 16, 2013 at 11:38 AM, Paul Burba <pt...@gmail.com> wrote:
> On Thu, May 16, 2013 at 11:32 AM, Stefan Sperling <st...@elego.de> wrote:
>> On Thu, May 16, 2013 at 05:07:08PM +0200, Bert Huijben wrote:
>>> I think we still do, but how can we determine if an incoming 'delete
>>> <this-exact-tree>' should apply to a node that is not there?
>>
>> It sounds like you are still talking about a merge into a sparse WC?
>> But that is not the problem, as Paul pointed out. The node to be
>> deleted is there during the merge into an infinite depth WC.
>>
>> Anyway, I believe the shallow merge is a red herring.
>>
>> During the merge at infinite depth, the tree to be deleted no the
>> branch does not match the tree deleted on the trunk:
>>
>> $ svn diff ^/A/B/E@6 A_COPY/B/E
>> Index: A_COPY/B/E/beta
>> ===================================================================
>> --- A_COPY/B/E/beta (file:///home/stsp/svn/svn-trunk/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-139/A/B/E) (revision 6)
>> +++ A_COPY/B/E/beta (.../A_COPY/B/E) (working copy)
>> @@ -1 +1 @@
>> -New content
>> \ No newline at end of file
>> +This is the file 'beta'.
>>
>> So I agree that the tree conflict flagged at the end of Paul's test
>> is warranted. The merge is not deleting the same tree as it was
>> deleting on trunk.
>>
>> If I tweak the test to not run a shallow merge, as below, the test
>> fails in the same way.
>>
>> $ svn diff
>> Index: merge_tests.py
>> ===================================================================
>> --- merge_tests.py (revision 1483398)
>> +++ merge_tests.py (working copy)
>> @@ -19026,8 +19026,8 @@ def merge_to_empty_target_merge_to_infinite_target
>> sbox.simple_commit()
>>
>> # r3 - Set depth of A_COPY to empty, merge the r3 from ^/A.
>> - svntest.actions.run_and_verify_svn(None, None, [], 'up',
>> - '--set-depth=empty', A_COPY_path)
>> + #svntest.actions.run_and_verify_svn(None, None, [], 'up',
>> + # '--set-depth=empty', A_COPY_path)
>> svntest.actions.run_and_verify_svn(None, None, [], 'merge', '-c7',
>> '^/A', A_COPY_path)
>> sbox.simple_commit()
>
> Doh! /me slaps self on forehead
>
> Ok, I'm with you on now. My test's expectations are flawed. But
> Bob's script is a different beast, there is a real problem there. I
> will rewrite the test to demonstrate his scenario.
r1483555
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Re: Sparse working copy in 1.8.0 causes problems for others' merges; 1.7.x didn't complain
Posted by Philip Martin <ph...@wandisco.com>.
Paul Burba <pt...@gmail.com> writes:
>> sqlite3 wc/.svn/wc.db "select op_depth, local_relpath, presence, repos_path, revision from nodes order by op_depth, local_relpath"
>> 0||normal|B|6
>> 0|P|normal|B/P|6
>> 0|X|normal|B/X|6
>> 2|P/Q|normal|T/P/Q|6
>> 2|P/Q/R|normal|T/P/Q/R|6
>> 3|P/Q/R|base-deleted||
>>
>> The merge has created a bogus copy, it has the path structure associated
>> with r3 but is marked r6.
>
> Fixed this in http://svn.apache.org/viewvc?view=revision&revision=1483947
>
> I'm confident this fix is correct, but would appreciate any review,
> since this is a convoluted use case.
Great! I was experimenting with the same patch locally but as I'm not
familiar with the merge code I wasn't sure whether I should commit it.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Sparse working copy in 1.8.0 causes problems for others' merges;
1.7.x didn't complain
Posted by Paul Burba <pt...@gmail.com>.
On Thu, May 16, 2013 at 1:58 PM, Philip Martin
<ph...@wandisco.com> wrote:
> Paul Burba <pt...@gmail.com> writes:
>
>> Bob's script is a different beast, there is a real problem there. I
>> will rewrite the test to demonstrate his scenario.
>
> It doesn't matter whether we use 1.7 or 1.8 for this:
>
> rm -rf repo wc
> svnadmin create repo --compatible-version 1.7
> svn -mm mkdir --parents file://`pwd`/repo/T/P
> svn -mm cp file://`pwd`/repo/T ^/B
> svn -mm mkdir --parents file://`pwd`/repo/T/P/Q/R
> svn -mm mkdir file://`pwd`/repo/T/X
> svn -mm rm file://`pwd`/repo/T/P/Q/R
> svn co --depth empty file://`pwd`/repo/B wc
> svn merge ^/T wc
> svn ci -mm wc
>
> Both 1.7 and 1.8 give this history:
>
> svn log file://`pwd`/repo -vq
> ------------------------------------------------------------------------
> r6 | pm | 2013-05-16 18:38:44 +0100 (Thu, 16 May 2013)
> Changed paths:
> M /B
> A /B/X (from /T/X:5)
> ------------------------------------------------------------------------
> r5 | pm | 2013-05-16 18:38:43 +0100 (Thu, 16 May 2013)
> Changed paths:
> D /T/P/Q/R
> ------------------------------------------------------------------------
> r4 | pm | 2013-05-16 18:38:43 +0100 (Thu, 16 May 2013)
> Changed paths:
> A /T/X
> ------------------------------------------------------------------------
> r3 | pm | 2013-05-16 18:38:43 +0100 (Thu, 16 May 2013)
> Changed paths:
> A /T/P/Q
> A /T/P/Q/R
> ------------------------------------------------------------------------
> r2 | pm | 2013-05-16 18:38:43 +0100 (Thu, 16 May 2013)
> Changed paths:
> A /B (from /T:1)
> ------------------------------------------------------------------------
> r1 | pm | 2013-05-16 18:38:43 +0100 (Thu, 16 May 2013)
> Changed paths:
> A /T
> A /T/P
> ------------------------------------------------------------------------
> svn pg svn:mergeinfo file://`pwd`/repo/B
> /T:2-5*
>
> This merge fails with 1.8:
>
> svn co file://`pwd`/repo/B wc
> svn merge ^/T wc
> svn ci -mm wc
> svn: E160028: '/B/P/Q/R' is out of date
>
> But the same merge works with 1.7 giving this commit:
>
> r7 | pm | 2013-05-16 18:54:02 +0100 (Thu, 16 May 2013)
> Changed paths:
> M /B
> A /B/P/Q (from /T/P/Q:3)
> D /B/P/Q/R
>
> The reason 1.8 fails is that it is not copying T/P/Q from the old r3 but
> from head. With 1.7 the wc.db before the commit looks like:
>
> sqlite3 wc/.svn/wc.db "select op_depth, local_relpath, presence, repos_path, revision from nodes order by op_depth, local_relpath"
> 0||normal|B|6
> 0|P|normal|B/P|6
> 0|X|normal|B/X|6
> 2|P/Q|normal|T/P/Q|3
> 2|P/Q/R|normal|T/P/Q/R|3
> 3|P/Q/R|base-deleted||
>
> but with 1.8 it looks like:
>
> sqlite3 wc/.svn/wc.db "select op_depth, local_relpath, presence, repos_path, revision from nodes order by op_depth, local_relpath"
> 0||normal|B|6
> 0|P|normal|B/P|6
> 0|X|normal|B/X|6
> 2|P/Q|normal|T/P/Q|6
> 2|P/Q/R|normal|T/P/Q/R|6
> 3|P/Q/R|base-deleted||
>
> The merge has created a bogus copy, it has the path structure associated
> with r3 but is marked r6.
Fixed this in http://svn.apache.org/viewvc?view=revision&revision=1483947
I'm confident this fix is correct, but would appreciate any review,
since this is a convoluted use case.
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Re: Sparse working copy in 1.8.0 causes problems for others' merges; 1.7.x didn't complain
Posted by Philip Martin <ph...@wandisco.com>.
Paul Burba <pt...@gmail.com> writes:
> Bob's script is a different beast, there is a real problem there. I
> will rewrite the test to demonstrate his scenario.
It doesn't matter whether we use 1.7 or 1.8 for this:
rm -rf repo wc
svnadmin create repo --compatible-version 1.7
svn -mm mkdir --parents file://`pwd`/repo/T/P
svn -mm cp file://`pwd`/repo/T ^/B
svn -mm mkdir --parents file://`pwd`/repo/T/P/Q/R
svn -mm mkdir file://`pwd`/repo/T/X
svn -mm rm file://`pwd`/repo/T/P/Q/R
svn co --depth empty file://`pwd`/repo/B wc
svn merge ^/T wc
svn ci -mm wc
Both 1.7 and 1.8 give this history:
svn log file://`pwd`/repo -vq
------------------------------------------------------------------------
r6 | pm | 2013-05-16 18:38:44 +0100 (Thu, 16 May 2013)
Changed paths:
M /B
A /B/X (from /T/X:5)
------------------------------------------------------------------------
r5 | pm | 2013-05-16 18:38:43 +0100 (Thu, 16 May 2013)
Changed paths:
D /T/P/Q/R
------------------------------------------------------------------------
r4 | pm | 2013-05-16 18:38:43 +0100 (Thu, 16 May 2013)
Changed paths:
A /T/X
------------------------------------------------------------------------
r3 | pm | 2013-05-16 18:38:43 +0100 (Thu, 16 May 2013)
Changed paths:
A /T/P/Q
A /T/P/Q/R
------------------------------------------------------------------------
r2 | pm | 2013-05-16 18:38:43 +0100 (Thu, 16 May 2013)
Changed paths:
A /B (from /T:1)
------------------------------------------------------------------------
r1 | pm | 2013-05-16 18:38:43 +0100 (Thu, 16 May 2013)
Changed paths:
A /T
A /T/P
------------------------------------------------------------------------
svn pg svn:mergeinfo file://`pwd`/repo/B
/T:2-5*
This merge fails with 1.8:
svn co file://`pwd`/repo/B wc
svn merge ^/T wc
svn ci -mm wc
svn: E160028: '/B/P/Q/R' is out of date
But the same merge works with 1.7 giving this commit:
r7 | pm | 2013-05-16 18:54:02 +0100 (Thu, 16 May 2013)
Changed paths:
M /B
A /B/P/Q (from /T/P/Q:3)
D /B/P/Q/R
The reason 1.8 fails is that it is not copying T/P/Q from the old r3 but
from head. With 1.7 the wc.db before the commit looks like:
sqlite3 wc/.svn/wc.db "select op_depth, local_relpath, presence, repos_path, revision from nodes order by op_depth, local_relpath"
0||normal|B|6
0|P|normal|B/P|6
0|X|normal|B/X|6
2|P/Q|normal|T/P/Q|3
2|P/Q/R|normal|T/P/Q/R|3
3|P/Q/R|base-deleted||
but with 1.8 it looks like:
sqlite3 wc/.svn/wc.db "select op_depth, local_relpath, presence, repos_path, revision from nodes order by op_depth, local_relpath"
0||normal|B|6
0|P|normal|B/P|6
0|X|normal|B/X|6
2|P/Q|normal|T/P/Q|6
2|P/Q/R|normal|T/P/Q/R|6
3|P/Q/R|base-deleted||
The merge has created a bogus copy, it has the path structure associated
with r3 but is marked r6.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Sparse working copy in 1.8.0 causes problems for others' merges;
1.7.x didn't complain
Posted by Paul Burba <pt...@gmail.com>.
On Thu, May 16, 2013 at 11:32 AM, Stefan Sperling <st...@elego.de> wrote:
> On Thu, May 16, 2013 at 05:07:08PM +0200, Bert Huijben wrote:
>> I think we still do, but how can we determine if an incoming 'delete
>> <this-exact-tree>' should apply to a node that is not there?
>
> It sounds like you are still talking about a merge into a sparse WC?
> But that is not the problem, as Paul pointed out. The node to be
> deleted is there during the merge into an infinite depth WC.
>
> Anyway, I believe the shallow merge is a red herring.
>
> During the merge at infinite depth, the tree to be deleted no the
> branch does not match the tree deleted on the trunk:
>
> $ svn diff ^/A/B/E@6 A_COPY/B/E
> Index: A_COPY/B/E/beta
> ===================================================================
> --- A_COPY/B/E/beta (file:///home/stsp/svn/svn-trunk/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-139/A/B/E) (revision 6)
> +++ A_COPY/B/E/beta (.../A_COPY/B/E) (working copy)
> @@ -1 +1 @@
> -New content
> \ No newline at end of file
> +This is the file 'beta'.
>
> So I agree that the tree conflict flagged at the end of Paul's test
> is warranted. The merge is not deleting the same tree as it was
> deleting on trunk.
>
> If I tweak the test to not run a shallow merge, as below, the test
> fails in the same way.
>
> $ svn diff
> Index: merge_tests.py
> ===================================================================
> --- merge_tests.py (revision 1483398)
> +++ merge_tests.py (working copy)
> @@ -19026,8 +19026,8 @@ def merge_to_empty_target_merge_to_infinite_target
> sbox.simple_commit()
>
> # r3 - Set depth of A_COPY to empty, merge the r3 from ^/A.
> - svntest.actions.run_and_verify_svn(None, None, [], 'up',
> - '--set-depth=empty', A_COPY_path)
> + #svntest.actions.run_and_verify_svn(None, None, [], 'up',
> + # '--set-depth=empty', A_COPY_path)
> svntest.actions.run_and_verify_svn(None, None, [], 'merge', '-c7',
> '^/A', A_COPY_path)
> sbox.simple_commit()
Doh! /me slaps self on forehead
Ok, I'm with you on now. My test's expectations are flawed. But
Bob's script is a different beast, there is a real problem there. I
will rewrite the test to demonstrate his scenario.
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Re: Sparse working copy in 1.8.0 causes problems for others' merges;
1.7.x didn't complain
Posted by Stefan Sperling <st...@elego.de>.
On Thu, May 16, 2013 at 05:07:08PM +0200, Bert Huijben wrote:
> I think we still do, but how can we determine if an incoming 'delete
> <this-exact-tree>' should apply to a node that is not there?
It sounds like you are still talking about a merge into a sparse WC?
But that is not the problem, as Paul pointed out. The node to be
deleted is there during the merge into an infinite depth WC.
Anyway, I believe the shallow merge is a red herring.
During the merge at infinite depth, the tree to be deleted no the
branch does not match the tree deleted on the trunk:
$ svn diff ^/A/B/E@6 A_COPY/B/E
Index: A_COPY/B/E/beta
===================================================================
--- A_COPY/B/E/beta (file:///home/stsp/svn/svn-trunk/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-139/A/B/E) (revision 6)
+++ A_COPY/B/E/beta (.../A_COPY/B/E) (working copy)
@@ -1 +1 @@
-New content
\ No newline at end of file
+This is the file 'beta'.
So I agree that the tree conflict flagged at the end of Paul's test
is warranted. The merge is not deleting the same tree as it was
deleting on trunk.
If I tweak the test to not run a shallow merge, as below, the test
fails in the same way.
$ svn diff
Index: merge_tests.py
===================================================================
--- merge_tests.py (revision 1483398)
+++ merge_tests.py (working copy)
@@ -19026,8 +19026,8 @@ def merge_to_empty_target_merge_to_infinite_target
sbox.simple_commit()
# r3 - Set depth of A_COPY to empty, merge the r3 from ^/A.
- svntest.actions.run_and_verify_svn(None, None, [], 'up',
- '--set-depth=empty', A_COPY_path)
+ #svntest.actions.run_and_verify_svn(None, None, [], 'up',
+ # '--set-depth=empty', A_COPY_path)
svntest.actions.run_and_verify_svn(None, None, [], 'merge', '-c7',
'^/A', A_COPY_path)
sbox.simple_commit()
RE: Sparse working copy in 1.8.0 causes problems for others' merges; 1.7.x didn't complain
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Paul Burba [mailto:ptburba@gmail.com]
> Sent: donderdag 16 mei 2013 16:10
> To: Bert Huijben
> Cc: Bob Cardillo; dev
> Subject: Re: Sparse working copy in 1.8.0 causes problems for others'
> merges; 1.7.x didn't complain
>
> On Thu, May 16, 2013 at 3:59 AM, Bert Huijben <be...@qqmail.nl> wrote:
> >
> >> -----Original Message-----
> >> From: Paul Burba [mailto:ptburba@gmail.com]
> >> Sent: donderdag 16 mei 2013 01:47
> >> To: Bob Cardillo
> >> Cc: dev
> >> Subject: Re: Sparse working copy in 1.8.0 causes problems for others'
> >> merges; 1.7.x didn't complain
> >>
> >> On Wed, May 15, 2013 at 1:06 PM, Paul Burba <pt...@gmail.com>
> wrote:
> >> > On Mon, May 13, 2013 at 9:58 PM, Bob Cardillo
> <bo...@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
> >
> > I haven't looked at the specific details yet, but a specific behavior change
> between <= 1.7 and 1.8 is that Subversion 1.8 now compares the incoming
> delete with the local version of all nodes. (A TODO item since Subversion 1.6)
>
> Hi Bert,
>
> Is there an issue associated with this? Or could you just point me to
> a particular revision(s)?
>
> > If the incoming delete describes the delete of something else that what is
> available locally then the node is marked as tree conflicted.
> >
> > One very common case that this helps for is when nodes are moved. If a
> directory tree was changed before it was moved, then Subversion <= 1.7
> would just delete the old tree and insert a copy of whatever is merged in. -->
> You would lose track of the changes in the original location.
> >
> > I don't think this comparison code was really tested with sparse trees in
> mind. (We usually don't write detailed tests of cases we don't support)
>
> I'm confused...we don't support sparse working copies anymore? Also,
> to be clear, the problem doesn't appear to be with merges to shallow
> WCs. That seems to work as it did in 1.7. The problem occurs when
> merging to a uniform revision WC at infinite depth.
I think we still do, but how can we determine if an incoming 'delete <this-exact-tree>' should apply to a node that is not there?
In 1.6 and 1.7 we just deleted every directory tree, without verifying anything (and for files we did a limited check). This was a MAJOR todo left in our tree conflict implementation.
Even in a shallow working copy scenario, the delete of exactly what is not there is an unlikely operation: usually you would merges that apply to your tree.. Not merges that delete exactly what is not in your tree.
So if you commit you delete everything, and the mergetracking won't help you in any way as we can't store mergeinfo on a deleted node.
I would say that noting that you do something dangerous like this would be a good reason to give a tree conflict. The user can then decide: "yes this is what I intended to do", or "no, I shouldn't have applied this merge".
Maybe there is some middle ground where a few levels of directories apply to your working copy, and some deeper subdirectory is sparse. In this case I can see why you would want to apply the delete without further verifications... But in other cases I don't think you want that to be the default behavior.
Bert
Re: Sparse working copy in 1.8.0 causes problems for others' merges;
1.7.x didn't complain
Posted by Paul Burba <pt...@gmail.com>.
On Thu, May 16, 2013 at 3:59 AM, Bert Huijben <be...@qqmail.nl> wrote:
>
>> -----Original Message-----
>> From: Paul Burba [mailto:ptburba@gmail.com]
>> Sent: donderdag 16 mei 2013 01:47
>> To: Bob Cardillo
>> Cc: dev
>> Subject: Re: Sparse working copy in 1.8.0 causes problems for others'
>> merges; 1.7.x didn't complain
>>
>> On Wed, May 15, 2013 at 1:06 PM, Paul Burba <pt...@gmail.com> wrote:
>> > On Mon, May 13, 2013 at 9:58 PM, Bob Cardillo <bo...@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
>
> I haven't looked at the specific details yet, but a specific behavior change between <= 1.7 and 1.8 is that Subversion 1.8 now compares the incoming delete with the local version of all nodes. (A TODO item since Subversion 1.6)
Hi Bert,
Is there an issue associated with this? Or could you just point me to
a particular revision(s)?
> If the incoming delete describes the delete of something else that what is available locally then the node is marked as tree conflicted.
>
> One very common case that this helps for is when nodes are moved. If a directory tree was changed before it was moved, then Subversion <= 1.7 would just delete the old tree and insert a copy of whatever is merged in. --> You would lose track of the changes in the original location.
>
> I don't think this comparison code was really tested with sparse trees in mind. (We usually don't write detailed tests of cases we don't support)
I'm confused...we don't support sparse working copies anymore? Also,
to be clear, the problem doesn't appear to be with merges to shallow
WCs. That seems to work as it did in 1.7. The problem occurs when
merging to a uniform revision WC at infinite depth.
> And I'm not sure if just deleting not-compared trees without notification is really what you want here: it is quite possible that you lose track of changes this way. A tree conflict describes that you have to check yourself, while a plain delete says that everything is ok.
>
> You lost your changes in earlier versions of Subversion this way, but we already described that as a bug when we introduced tree conflicts in 1.6.
>
> Bert
>
>>
>> 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
>
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
RE: Sparse working copy in 1.8.0 causes problems for others' merges; 1.7.x didn't complain
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Paul Burba [mailto:ptburba@gmail.com]
> Sent: donderdag 16 mei 2013 01:47
> To: Bob Cardillo
> Cc: dev
> Subject: Re: Sparse working copy in 1.8.0 causes problems for others'
> merges; 1.7.x didn't complain
>
> On Wed, May 15, 2013 at 1:06 PM, Paul Burba <pt...@gmail.com> wrote:
> > On Mon, May 13, 2013 at 9:58 PM, Bob Cardillo <bo...@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
I haven't looked at the specific details yet, but a specific behavior change between <= 1.7 and 1.8 is that Subversion 1.8 now compares the incoming delete with the local version of all nodes. (A TODO item since Subversion 1.6)
If the incoming delete describes the delete of something else that what is available locally then the node is marked as tree conflicted.
One very common case that this helps for is when nodes are moved. If a directory tree was changed before it was moved, then Subversion <= 1.7 would just delete the old tree and insert a copy of whatever is merged in. --> You would lose track of the changes in the original location.
I don't think this comparison code was really tested with sparse trees in mind. (We usually don't write detailed tests of cases we don't support)
And I'm not sure if just deleting not-compared trees without notification is really what you want here: it is quite possible that you lose track of changes this way. A tree conflict describes that you have to check yourself, while a plain delete says that everything is ok.
You lost your changes in earlier versions of Subversion this way, but we already described that as a bug when we introduced tree conflicts in 1.6.
Bert
>
> 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
Re: Sparse working copy in 1.8.0 causes problems for others' merges;
1.7.x didn't complain
Posted by Paul Burba <pt...@gmail.com>.
On Wed, May 15, 2013 at 1:06 PM, Paul Burba <pt...@gmail.com> wrote:
> On Mon, May 13, 2013 at 9:58 PM, Bob Cardillo <bo...@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
Re: Sparse working copy in 1.8.0 causes problems for others' merges;
1.7.x didn't complain
Posted by Paul Burba <pt...@gmail.com>.
On Mon, May 13, 2013 at 9:58 PM, Bob Cardillo <bo...@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.
> Here's the complete recipe for Windows (it creates the repository from
> scratch, so the only assumption is that you have a C: drive):
> cd /d C:\
> svnadmin create test_repo
>
> svn checkout file:///C:/test_repo svntestrepo
>
> cd svntestrepo
> md trunk
> cd trunk
> md B
> md C
> cd ..
> md branches
> svn add branches
> svn add trunk
> svn commit -m ""
> svn copy "^/trunk" "^/branches/branch1" -m ""
>
> svn checkout "^/branches/branch1" ..\testbranch1_userX
>
> svn checkout --depth empty "^/branches/branch1" ..\testbranch1_userY
> cd ..\testbranch1_userY
> svn update --set-depth infinity C
>
> svn checkout "^/trunk" ..\testtrunk
>
> cd ..\testtrunk\B
> md B1
> cd B1
> echo B1 test > test.txt
> md B1a
> cd B1a
> echo B1a test > test.txt
> cd ..\..
> svn add B1
> cd ..
> svn commit -m ""
>
> cd C
> md C1
> cd C1
> echo C1 test > test.txt
> cd ..
> svn add C1
> cd ..
> svn commit -m ""
>
> cd B\B1
> svn delete B1a
> cd ..\..
> svn commit -m ""
>
> cd ..\testbranch1_userY
> svn merge "^/trunk"
> svn commit -m ""
>
> cd ..\testbranch1_userX
> svn update
> svn merge "^/trunk"
> svn commit -m ""
>
> Thanks!
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba