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

Re: Tree conflict resolution options on command-line

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 4 Aug 2014 08:48:56 +0200

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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.