On Wed, 2008-11-12 at 10:29 +0100, Stephen Butler wrote:
> Quoting "Neels J. Hofmeyr" <neels_at_elego.de>:
>
> > Hey guys,
> >
> > while trying to write a test for my most recent fix ("resolved" with
> > --depth), I found a most horrendous failure in tree-conflicts reporting
> > during update.
> >
> > See r34153 (on branch tc-resolve), inline comments in depth_tests.py's
> > function make_depth_tree_conflicts(), marked "##". :O
> >
> > Had no time to investigate yet.
> >
> > ~Neels
> >
>
> Hi Neels,
>
> I thinks this is a case where update "functions as designed". ;-)
> The setup commits r2 with a prop edit to dir E and a text edit to
> file E/alpha. In a working copy at r1, dir E is deleted. The
> update tries to open E to apply the edits, but raises (one) tree
> conflict because E is scheduled for deletion.
But:
CMD: svn up ...
C svn-test-work/working_copies/depth_tests-35/A/B/lambda
C svn-test-work/working_copies/depth_tests-35/A/B/E/alpha
C svn-test-work/working_copies/depth_tests-35/A/B/E
The main point is that 'lambda' is not inside E, it is a sibling of E,
so it gets its own conflict. So far so good.
A secondary point is that the notification showed a conflict on
'E/alpha' as well as on 'E', which is arguably not great.
But then the "svn status" is inconsistet: it doesn't show conflict on
'lambda':
CMD: svn status -v -u -q ...
D 2 1 jrandom /A/B/E/beta
D C * 1 1 jrandom /A/B/E/alpha
D C 2 2 jrandom /A/B/E
D * 1 1 jrandom /A/B/lambda
2 1 jrandom /A/B/F
...
- Julian
> This is use case 1 in notes/tree_conflicts/detection.txt. Any
> number of incoming changes to the locally-deleted tree are
> "condensed" into one tree conflict, because they are all blocked
> for the same reason.
>
> I guess we need to test each depth scenario in its own tree.
>
> Steve
>
>
---------------------------------------------------------------------
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-12 20:30:09 CET