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

RE: svn resolve --accept option

From: Bert Huijben <bert_at_qqmail.nl>
Date: Thu, 11 Oct 2012 18:50:30 +0200

Please use plain text on this list as it makes it much easier to answer in


The magic word is 'Tree conflict'. You can't resolve tree conflicts to
different states yet.

You can resolve text and property conflicts to those other states.


If you just want to resolve to working you can use the now deprecated 'svn
resolved PATH'.


Having it default to a specific value makes it very hard to implement the
resolving in a future version of Subversion; and this is exactly what we try
to do.




From: Gavin Baumanis [mailto:gavinb_at_thespidernet.com]
Sent: donderdag 11 oktober 2012 18:42
To: dev_at_subversion.apache.org
Subject: svn resolve --accept option


Hi Everyone,


I just recently had cause to resolve a tree conflict, so I used the

svn resolve www\en\assets\Homepage_Images


from this I received the following error message;

svn: E205000: Try 'svn help' for more info

svn: E205000: missing --accept option


so I entered the following;

svn resolve www\en\assets\Homepage_Images --accept theirs-full


which gave me;

svn: warning: W155027: Tree conflicts can only be resolved to 'working'
state; 'C:\Matilda\www\en\assets\Homepage_Images' not resolved



So ultimately my question is;

If you are performing a 'svn resolve --accept' why isn't the "working"
attribute just assumed / enforced internally?


I can see the value in making it a "positive" choice to actually have to
choose "working" - as opposed to it being an assumption, but since it is the
only available option - Is it really such a big deal to have the automatic



Received on 2012-10-11 18:51:07 CEST

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