On Mon, Feb 9, 2009 at 1:18 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> On Sun, 2009-02-08 at 21:08 -0500, Paul Burba wrote:
>> While working on the Issue #3334 branch I keep coming across many
>> cases where we update and end up with a WC that can't be resolved and
>> committed. Usually the desired behavior is pretty obvious, but
>> update_tests.py 33 'update wc containing a replaced-with-history file'
>> demonstrates a case I'm not very certain about: An update brings down
>> a text edit on file that is locally replaced without history:
>>
>> # We have this WC:
>>
>> TRUNK.DBG>svn st -v update_tests-33
>> 1 1 jrandom update_tests-33
>> 1 1 jrandom update_tests-33\A
>> 1 1 jrandom update_tests-33\A\B
>> 1 1 jrandom update_tests-33\A\B\lambda
>> 1 1 jrandom update_tests-33\A\B\E
>> 1 1 jrandom update_tests-33\A\B\E\alpha
>> 1 1 jrandom update_tests-33\A\B\E\beta
>> 1 1 jrandom update_tests-33\A\B\F
>> 1 1 jrandom update_tests-33\A\mu
>> 1 1 jrandom update_tests-33\A\C
>> 1 1 jrandom update_tests-33\A\D
>> 1 1 jrandom update_tests-33\A\D\gamma
>> 1 1 jrandom update_tests-33\A\D\G
>> 1 1 jrandom update_tests-33\A\D\G\pi
>> 1 1 jrandom update_tests-33\A\D\G\rho
>> 1 1 jrandom update_tests-33\A\D\G\tau
>> 1 1 jrandom update_tests-33\A\D\H
>> 1 1 jrandom update_tests-33\A\D\H\chi
>> 1 1 jrandom update_tests-33\A\D\H\omega
>> 1 1 jrandom update_tests-33\A\D\H\psi
>> R 1 1 jrandom update_tests-33\iota
>>
>>
>> TRUNK.DBG>svn diff update_tests-33
>> Index: update_tests-33/iota
>> ===================================================================
>> --- update_tests-33/iota (revision 1)
>> +++ update_tests-33/iota (working copy)
>> @@ -1 +0,0 @@
>> -This is the file 'iota'.
>
> So, the 1-line file is being replaced with a 0-line (empty) file. Is
> that what the following line does?
>
> svntest.main.run_svn(None, 'cp', mu_path, iota_path)
>
> It looks like that diff is broken. Shouldn't it include "+This is the
> file 'mu'." ?
Hi Julian,
I should have pointed out that the above WC state is that prior to the
*first* update in update_tests.py 33 -- see the update after '# First,
a replacement without history.' The test does this first, reverts,
then tries an update which brings a mod down on a
replaced-with-history file.
>> # Here is the incoming text change:
>>
>> TRUNK.DBG>svn diff update_tests-33\iota -r1:HEAD
>> Index: update_tests-33/iota
>> ===================================================================
>> --- update_tests-33/iota (revision 1)
>> +++ update_tests-33/iota (revision 2)
>> @@ -1 +1,2 @@
>> This is the file 'iota'.
>> +New line in 'iota'
>>
>> # We update and get the expected tree conflict:
>>
>> TRUNK.DBG>svn up update_tests-33
>> Skipped 'update_tests-33\iota'
>> At revision 2.
>> Summary of conflicts:
>> Skipped paths: 1
>
> That flagged a tree conflict? Then it should say so, and not say just
> "skipped" without saying why.
Oops, copied the wrong thing there, it should be:
TRUNK.DBG>svn up update_tests-33
C update_tests-33\iota
At revision 2.
Summary of conflicts:
Tree conflicts: 1
>> # But iota is still at rev 1...
>>
>> TRUNK.DBG>svn st update_tests-33 -v
>> 2 2 jrandom update_tests-33
>> 2 1 jrandom update_tests-33\A
>> 2 1 jrandom update_tests-33\A\B
>> 2 1 jrandom update_tests-33\A\B\lambda
>> 2 1 jrandom update_tests-33\A\B\E
>> 2 1 jrandom update_tests-33\A\B\E\alpha
>> 2 1 jrandom update_tests-33\A\B\E\beta
>> 2 1 jrandom update_tests-33\A\B\F
>> 2 1 jrandom update_tests-33\A\mu
>> 2 1 jrandom update_tests-33\A\C
>> 2 1 jrandom update_tests-33\A\D
>> 2 1 jrandom update_tests-33\A\D\gamma
>> 2 1 jrandom update_tests-33\A\D\G
>> 2 1 jrandom update_tests-33\A\D\G\pi
>> 2 1 jrandom update_tests-33\A\D\G\rho
>> 2 1 jrandom update_tests-33\A\D\G\tau
>> 2 1 jrandom update_tests-33\A\D\H
>> 2 1 jrandom update_tests-33\A\D\H\chi
>> 2 1 jrandom update_tests-33\A\D\H\omega
>> 2 1 jrandom update_tests-33\A\D\H\psi
>> R C 1 1 jrandom update_tests-33\iota
>> > local delete, incoming edit upon update
>
> OK, so it did flag a tree conflict. (I think it's OK that we report
> "local delete" and not "local replacement".)
The delete half of the replace and the incoming edit are what accounts
for the tree conflict, so that makes sense to me too.
> That's good in that it flagged the conflict, but bad in that it does not
> update the base-revision, as shown by the "1" instead of "2" there.
>
>> TRUNK.DBG>svn diff update_tests-33
>> Index: update_tests-33/iota
>> ===================================================================
>> --- update_tests-33/iota (revision 1)
>> +++ update_tests-33/iota (working copy)
>> @@ -1 +0,0 @@
>> -This is the file 'iota'.
>
> And we haven't applied the incoming change to the text-base. Oops.
> (Being a replacement, the text-base we're talking about is the one
> called "revert-base".)
>
>> # ...So even if we resolve, we can't commit because 'iota' is out of date.
>> # (and of course if we update we are back in the same position)
> [...]
>
>> So what would we like to see for behavior here? Should the text base
>> for iota simply be updated and a tree conflict generated on the delete
>> half of the replace, leaving us with a WC like this?
>>
>> BETTER???>svn st update_tests-33 -v
>> 2 2 jrandom update_tests-33
>> 2 1 jrandom update_tests-33\A
>> 2 1 jrandom update_tests-33\A\B
>> 2 1 jrandom update_tests-33\A\B\lambda
>> 2 1 jrandom update_tests-33\A\B\E
>> 2 1 jrandom update_tests-33\A\B\E\alpha
>> 2 1 jrandom update_tests-33\A\B\E\beta
>> 2 1 jrandom update_tests-33\A\B\F
>> 2 1 jrandom update_tests-33\A\mu
>> 2 1 jrandom update_tests-33\A\C
>> 2 1 jrandom update_tests-33\A\D
>> 2 1 jrandom update_tests-33\A\D\gamma
>> 2 1 jrandom update_tests-33\A\D\G
>> 2 1 jrandom update_tests-33\A\D\G\pi
>> 2 1 jrandom update_tests-33\A\D\G\rho
>> 2 1 jrandom update_tests-33\A\D\G\tau
>> 2 1 jrandom update_tests-33\A\D\H
>> 2 1 jrandom update_tests-33\A\D\H\chi
>> 2 1 jrandom update_tests-33\A\D\H\omega
>> 2 1 jrandom update_tests-33\A\D\H\psi
>> R C 2 1 jrandom update_tests-33\iota
>> > local delete, incoming edit upon update
>>
>> BETTER???>svn diff update_tests-33
>> Index: update_tests-33/iota
>> ===================================================================
>> --- update_tests-33/iota (revision 2)
>> +++ update_tests-33/iota (working copy)
>> @@ -1,2 +0,0 @@
>> -This is the file 'iota'.
>> -New line in 'iota'
>
> Yes, of course. That is both good and consistent with the behaviour that
> we're getting (trying to get) in the other issue-3334 and similar cases,
> is it not?
Yes, I think it is, I wanted to be sure at least someone else thought so too.
Re the 3334 branch, I've got a patch that addresses every other case
of incoming edits/deletes on/within locally deleted trees. I'm
working on making it handle the replace scenario above too. Once I'm
done I'll post the patch on the 'Help on 1.6-blocker #3334 - tree
conflicts in update' thread.
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1130460
Received on 2009-02-09 21:56:23 CET