[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Need to resolve expected behavior of XFailing tests caused by tree conflicts (Issue #3209)

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Wed, 21 Jan 2009 20:49:19 +0200 (Jerusalem Standard Time)

Paul Burba wrote on Tue, 20 Jan 2009 at 16:07 -0500:
> =======
> =======
> update_tests.py 31 'forced up fails with some types of obstructions'
> This test fails when we a (--forced) update tries to add a directory
> when a versioned directory of the same name already exists.
> Admittedly this is quite a contrived situation: The test adds a
> directory A/C/I in r2, updates A/C to r1, then checks out %URL%/A/C/I
> directly to A/C/I in the WC. This leaves us with a situation where
> A/C thinks A/C/I is some unversioned item:
> It strikes me that *both* of these behaviors are probably wrong.
> Shouldn't the update simply tolerate A/C/I's presence and simply bring
> A/C up to r2? Though if A/C/I pointed to a different location then
> there should be an error, but what?

Makes sense. And, under --force, we can (instead of throw an error)
mark the item as switched or obstructed.

> FWIW this doesn't seem a very common use case.

Yesterday I ran into a variant of this:

    % svn co URL_TO_trunk/foo path/to/foo
    % # three days later...
    % svn co URL_TO_trunk path/to --force
    (marked 'foo' as a tree conflict)
    (but I hoped that it would trigger the 'E'xisted behaviour)

> The old behavior was added by me back with the r20945 'takeover'
> functionality, and IIRC it was simply because this was a possibility
> and the code had to do *something* in this case.

Received on 2009-01-21 20:00:49 CET

This is an archived mail posted to the Subversion Dev mailing list.