On Mon, Aug 04, 2014 at 02:05:33PM +1000, Daniel Becroft wrote:
> Hi,
>
> Using: svn 1.8.8 (r1568071)
>
> When attempting to merge a change into my working copy, I am getting a tree
> conflict (change adds a file, file already exists). No problem with the
> conflict.
>
> Conflict discovered when trying to add 'foo\A\B\c.p'.
> An object of the same name already exists.
> Select: (mf) my version, (tf) their version, (p) postpone,
> (q) quit resolution, (h) help:
>
> If I select to use either of 'mf' or 'tf', I get:
>
> Summary of conflits:
> Tree conflicts: 0 remainings (and 1 already resolved)
> svn: E155027: Tree conflict can only be resolved to 'working' state;
> 'foo\A\B\c.p' not resolved.
>
> My question is: If a tree conflict can only ever be resolved to 'working',
> then
> (a) why isn't 'working' an option in the resolution prompt?; and
> (b) why am I being asked to choose something that isn't applicable anyway?
>
> ---
> Daniel Becroft
There used to be only the 'svn resolved' command (with a 'd'), which clears
conflict markers in meta data but otherwise leaves the working copy unchanged.
This is equivalent to what 'svn --accept working' does today and "resolve to
working state" became an expression for clearing conflict markers without
making any other changes to the current working copy state. This wording
has been used in the prompt. I'm not sure if that's good from a UI point of
view, but (from a developer's point of view) it doesn't sound very far fetched.
As to why you're being asked, I suspect these options did something at some
point in time, perhaps in Subversion 1.5. Since then, lots of things have changed
and the menus aren't being tested properly. There are no automated tests for them
so inconsistencies tend to creep in over time.
Received on 2014-08-04 08:49:42 CEST