Re: update_tests.py 50 XFails.

Julian Foad wrote:
> On Wed, 2008-11-26 at 06:32 +0100, Neels J Hofmeyr wrote:
>> Hyrum K. Wright wrote:
>>> XFAIL: update_tests.py 50: tree conflicts on update 2.3
>> This one is failing for no real reason. Let me explain.
>> The error:
>> [[[
>> ENTERING DIR: /.../local_leaf_edit_incoming_tree_del/D/D1
>> CMD: svn up "" --config-dir /.../local_tmp/config --password rayjandom
>> --no-auth-cache --username jrandom
>> exited with 1
>> <TIME = 0.027884>
>> subversion/libsvn_repos/reporter.c:1162: (apr_err=160005)
>> svn: Target path '/local_leaf_edit_incoming_tree_del/D/D1' does not exist
>> ]]]
>>
>> This is an update with an incoming tree del. In English, that means that the
>> path D/D1 has been deleted in the repository.
>>
>> So, the target of the delete does not exist. That actually makes sense.
>
> No, I'm not sure that does make sense. "Target", to the command-line
> user, means the object "" to which the "update" command was applied.
> This directory certainly exists on disk, and it is also known to
> Subversion. "Target" in this error message, however, I think means the
> target of some repository-side operation. I haven't time to investigate
> now, but I suspect this is a symptom of something wrong in our code.
>
>
>> But the problem is, this error is only issued when going into D/D1/ in
>> the local working copy and running `svn up ""'.
>>
>> If going to D/ and running `svn up D1', it says, correctly, that D1 is
>> tree-conflicted.
>
> For clarity: it says that D1 becomes tree-conflicted by this attempt to
> delete it. Yes?

Ah sorry, I wasn't being clear. This is a situation where a tree-conflict
already exists. Now the test makes sure that running "svn up" skips all
*already* tree-conflicted nodes.

So, if there is a tree-conflict on D/D1, D's THIS_DIR entry will have D1's
tree-conflict info. The case in question now is, if you cd into D/D1, then
run an 'svn up ""', should we go walk outwards from D/D1 to D/ (and to the
working copy root), to check whether any ancestor is currently
tree-conflicted? We'd need read locks on them too, right?

I think eventually we'll have to do either this, or to walk the complete
subtree of each new tree-conflict, marking it as "tree-conflicted-ancestry"
or something, again removing that flag everywhere when resolving.

Or we say: "When you have a tree-conflicted dir, don't go inside it please
before resolving it", well, something like that. And wait for wc-ng, where
hopefully it might be simpler to store such information.

Comments??
~Neels

>
>> This has to be so! When going to D, we have the benefit of knowing the
>> tree-conflict info on D1, because it is stored in D's THIS_DIR entry.
>> But when within D1, and without stepping upwards in the working copy past
>> the current working directory, whe can't possibly know that D1 is
>> tree-conflicted.
>
> I would describe it as: if we are within "D1" then we can't raise a tree
> conflict on D1 because we don't allow ourselves to gain write access to
> its parent in this situation.
>
> Does that make sense?
>
> - Julian
>
>
>> Also imagine the case that we were at D/D1/D2/D3/D456 when D1 was the
>> actually deleted one that has a tree-conflict. We can't say that
>> D/D1/D2/D3/D456 is tree-conflicted, because there is no info in D3 about
>> D456. Particularly, we won't go stepping into parent dirs until we find one
>> that still exists and raise a conflict on its child. No, we should simply
>> say: "Target path '%s' does not exist". q.e.d.?
>>
>> ~Neels
>>
>>> XFAIL: switch_tests.py 21: forced switch detects tree conflicts
>>> XFAIL: log_tests.py 21: test log -c on range of changes
>>> XFAIL: log_tests.py 22: test log -c on comma-separated list of changes
>>> XFAIL: diff_tests.py 49: diff URL against working copy with local mods
>>> XFAIL: diff_tests.py 50: diff -r1 of removed file to its local addition
>>> XFAIL: merge_tests.py 19: merge should skip over unversioned obstructions
>>> XFAIL: merge_tests.py 20: merge into missing must not break working copy
>>> XFAIL: merge_tests.py 33: merge a replacement of a directory
>>> XFAIL: merge_tests.py 39: conflict from merge of add over versioned file
>>> XFAIL: merge_tests.py 68: mergeinfo recording in skipped merge
>>> XFAIL: merge_tests.py 91: merge added subtree
>>> XFAIL: merge_tests.py 125: merge prior to rename src existence still dels src
>>> XFAIL: info_tests.py 2: info on added file
>>> XFAIL: tree_conflict_tests.py 8: up/sw dir: add onto add
>>> XFAIL: tree_conflict_tests.py 14: merge dir: del/rpl/mv onto not-same
>>>
>>> Some of these may be new tests in 1.6, others might just be bad expected output,
>>> and yet others may be regressions from 1.5. Are there any volunteers to take a
>>> look at the above tests and either fix them, or classify them into one of the
>>> above categories so that others can fix them?
>>>
>>> Thanks,
>>> -Hyrum
>>>
>