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?
> 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
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-28 23:50:00 CET