[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
line.

 

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.

 

                Bert

 

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
following;

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
treatment?

 

 

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

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