Hi Paul,
I just committed to the 3334 branch a new test in update_tests.py,
in the style of the UC2 schedule-re-add test, but for UC1. It may
shed some light on the problem.
Basically we have to fiddle with all the open_*, add_* and close_*
callbacks in the update editor, to get rid of the skipping for UC1.
I've hacked at them for some hours, but now I've lowered my sights
to simply making add_file() use the same logic as add_directory(),
because add_file() raises tree conflicts too often. But once I
have that down, I'll return to the bigger problem.
cheers,
Steve
Quoting Paul Burba <ptburba_at_gmail.com>:
> On Wed, Feb 4, 2009 at 12:59 AM, Paul Burba <ptburba_at_gmail.com> wrote:
>> On Thu, Jan 29, 2009 at 9:09 AM, Paul Burba <ptburba_at_gmail.com> wrote:
>>> On Wed, Jan 28, 2009 at 3:48 PM, Julian Foad
>>> <julianfoad_at_btopenworld.com> wrote:
>>>> Blocker:
>>>>>
>>>>> * #3334: Tree conflicts "merry-go-round" about update updating the base.
>>>>> Julian Foad is working on this. Done for when victim is a file, still
>>>>> doing for when victim is a directory. [julianfoad]
>>>>> See:
>>>>> <http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1019712>.
>>>>
>>>> I'm struggling with this and could use some help. I have rather little
>>>> time to look at it these days.
>>>>
>>>> On the issue-3334-dirs branch, the remaining problem is "just" a matter
>>>> of scheduling a directory tree to be re-added as a copy of what it was
>>>> before.
>>>>
>>>> The function "schedule_existing_item_for_re_add()" tries to do this, but
>>>> doesn't get the result quite right.
>>>>
>>>> On the branch I added a new "test" (update_tests.py 53). This "test"
>>>> doesn't actually test anything, but just runs the tree-conflict
>>>> scenario, and also runs a manual schedule-as-re-add command sequence, so
>>>> that we can (manually) compare the resulting "entries" files.
>>>>
>>>> In test 53, the tree conflict victim is directory A/ and A's THIS_DIR
>>>> entry needs a "revision" of 1, but it gets a revision of 2. That's all
>>>> that is wrong with its THIS_DIR entry. There is nothing wrong with its
>>>> children, I think. The only other problem is A's entry in its parent,
>>>> which gets several fields wrong (different from the "manual copy" WC).
>>>>
>>>> Please could someone have a look at the differences between the entries
>>>> files in test 53's two WCs, and see how to make
>>>> "schedule_existing_item_for_re_add()" create that state.
>>>
>>> Julian,
>>>
>>> I'll look at this today...and probably tomorrow too I'm sure :-\
>>
>> I think I've got it, well most of it anyway, see r35667. I still need
>> to check the XFailing update and switch tests, they may need some
>> expectation adjustment. Also, switch_tests.py 33 'tree conflicts on
>> switch 2.1', while it passes, still shows a bunch of subtrees as
>> switched when they are not. This happens in trunk too, so it's
>> nothing new with this branch. I'll look into both tomorrow, but in
>> the meantime please take a look.
>
> Apparently in a late night haze, focused primarily on the re-add with
> history problem when deletes land on edits, I spoke too soon. The
> problem with switch test 33 is a bit more serious than I realized, it
> is a general problem with local tree deletes and incoming leaf deletes
> (as demonstrated by update_tests.py 47 and switch_tests.py 32).
>
> In both of those tests the open_directory callback, when operating on
> the root of the locally deleted tree, considers that there is a tree
> conflict of the edit-incoming-on-delete kind and stores this path in
> the edit baton's skipped_trees hash. Because the root of the tree is
> only locally deleted the delete_entry callback is never called for it,
> so we have no chance to do anything with it, e.g. fix the switched
> directory problem or remove its scheduled delete status. When the
> delete_entry callback is called for the incoming deleted leaf it sees
> that the leaf is in the skipped_trees hash and does nothing.
>
> For example, we have some local tree deletes:
>
> 3334.DBG>svn st update_tests-47 -v
> 2 2 jrandom update_tests-47
> 2 1 jrandom update_tests-47\A
> 2 1 jrandom update_tests-47\A\B
> 2 1 jrandom update_tests-47\A\B\lambda
> 2 1 jrandom update_tests-47\A\B\E
> 2 1 jrandom update_tests-47\A\B\E\alpha
> 2 1 jrandom update_tests-47\A\B\E\beta
> 2 1 jrandom update_tests-47\A\B\F
> 2 1 jrandom update_tests-47\A\mu
> 2 1 jrandom update_tests-47\A\C
> 2 1 jrandom update_tests-47\A\D
> 2 1 jrandom update_tests-47\A\D\gamma
> 2 1 jrandom update_tests-47\A\D\G
> 2 1 jrandom update_tests-47\A\D\G\pi
> 2 1 jrandom update_tests-47\A\D\G\rho
> 2 1 jrandom update_tests-47\A\D\G\tau
> 2 1 jrandom update_tests-47\A\D\H
> 2 1 jrandom update_tests-47\A\D\H\chi
> 2 1 jrandom update_tests-47\A\D\H\omega
> 2 1 jrandom update_tests-47\A\D\H\psi
> 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del
> 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\D
> D 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\D\D1
> 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\F
> D 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\F\alpha
> 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DD
> D 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DD\D1
> D 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DD\D1\D2
> 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DF
> D 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DF\D1
> D 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DF\D1\beta
> 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DDD
> D 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DDD\D1
> D 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DDD\D1\D2
> D 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DDD\D1\D2\D3
> 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DDF
> D 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DDF\D1
> D 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DDF\D1\D2
> D 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DDF\D1\D2\gamma
> 2 1 jrandom update_tests-47\iota
>
> And some incoming leaf deletes:
>
> 3334.DBG>svn log -v -r3 update_tests-47
> ------------------------------------------------------------------------
> r3 | jrandom | 2009-02-04 11:10:53 -0500 (Wed, 04 Feb 2009) | 1 line
> Changed paths:
> D /local_tree_del_incoming_leaf_del/D/D1
> D /local_tree_del_incoming_leaf_del/DD/D1/D2
> D /local_tree_del_incoming_leaf_del/DDD/D1/D2/D3
> D /local_tree_del_incoming_leaf_del/DDF/D1/D2/gamma
> D /local_tree_del_incoming_leaf_del/DF/D1/beta
> D /local_tree_del_incoming_leaf_del/F/alpha
>
> incoming changes
> ------------------------------------------------------------------------
>
> Update...
>
> 3334.DBG>svn up update_tests-47
> C update_tests-47\local_tree_del_incoming_leaf_del\D\D1
> C update_tests-47\local_tree_del_incoming_leaf_del\F\alpha
> C update_tests-47\local_tree_del_incoming_leaf_del\DD\D1
> C update_tests-47\local_tree_del_incoming_leaf_del\DF\D1
> C update_tests-47\local_tree_del_incoming_leaf_del\DDD\D1
> C update_tests-47\local_tree_del_incoming_leaf_del\DDF\D1
> At revision 3.
> Summary of conflicts:
> Tree conflicts: 6
>
>
> ...and oops, we are still on the merry-go-round (except in the two
> cases where the incoming delete lands directly on the root of the
> local delete, i.e. 'D/D1' and 'F/alpha', those are ok):
>
> 3334.DBG>svn st update_tests-47 -v
> 3 3 jrandom update_tests-47
> 3 1 jrandom update_tests-47\A
> 3 1 jrandom update_tests-47\A\B
> 3 1 jrandom update_tests-47\A\B\lambda
> 3 1 jrandom update_tests-47\A\B\E
> 3 1 jrandom update_tests-47\A\B\E\alpha
> 3 1 jrandom update_tests-47\A\B\E\beta
> 3 1 jrandom update_tests-47\A\B\F
> 3 1 jrandom update_tests-47\A\mu
> 3 1 jrandom update_tests-47\A\C
> 3 1 jrandom update_tests-47\A\D
> 3 1 jrandom update_tests-47\A\D\gamma
> 3 1 jrandom update_tests-47\A\D\G
> 3 1 jrandom update_tests-47\A\D\G\pi
> 3 1 jrandom update_tests-47\A\D\G\rho
> 3 1 jrandom update_tests-47\A\D\G\tau
> 3 1 jrandom update_tests-47\A\D\H
> 3 1 jrandom update_tests-47\A\D\H\chi
> 3 1 jrandom update_tests-47\A\D\H\omega
> 3 1 jrandom update_tests-47\A\D\H\psi
> 3 3 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del
> 3 3 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\D
> ! C
> update_tests-47\local_tree_del_incoming_leaf_del\D\D1
> > local delete, incoming delete upon update
> 3 3 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\F
> ! C
> update_tests-47\local_tree_del_incoming_leaf_del\F\alpha
> > local delete, incoming delete upon update
> 3 3 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DD
> D C 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DD\D1
> > local delete, incoming edit upon update
> D 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DD\D1\D2
> 3 3 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DF
> D C 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DF\D1
> > local delete, incoming edit upon update
> D 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DF\D1\beta
> 3 3 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DDD
> D C 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DDD\D1
> > local delete, incoming edit upon update
> D 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DDD\D1\D2
> D 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DDD\D1\D2\D3
> 3 3 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DDF
> D C 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DDF\D1
> > local delete, incoming edit upon update
> D 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DDF\D1\D2
> D 2 2 jrandom
> update_tests-47\local_tree_del_incoming_leaf_del\DDF\D1\D2\gamma
> 3 1 jrandom update_tests-47\iota
>
> Looking at this now, any insight appreciated.
>
> Paul
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1102813
>
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Received on 2009-02-04 21:48:10 CET