tree-conflicts: cd into conflicted

Hi tree-conflicts folks,

I've made two scripts that show how a commit and an update is actually still
attempted when inside a tree-conflicted dir. The second one shows that it is
 possible to get a tree-conflict within an already tree-conflicted dir.

Currently, this doesn't weigh as heavily because having a tree-conflicted
dir means that it was either
- deleted in the repos. Then ci/up inside it fails because the path doesn't
exist in the repos. Or
- deleted in the working copy. Even though the empty directory skeleton may
sill hang around, going into it and trying to ci will say "out of date".
Trying to update will create another tree-conflict, because the paths have
been removed in the repository.

But if we move on to updating the wc base, this stuff might actually follow
through with commits or updates within an already tree-conflicted subtree.

However, we should block this from being tried, even before attempting to
actually *do* a commit/update.

Maybe this can wait for wc-ng, though. It is not particularly easy to run
into this situation. We should, however, definitely mention this in the
documentation.

~Neels

Neels J Hofmeyr wrote:
> 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
>>>>
>