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

Re: enhancements for error reporting

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Wed, 18 May 2011 07:32:09 +0200

On Tue, May 17, 2011 at 22:55, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 05/17/2011 08:54 PM, Stefan Küng wrote:
>> Hi,
>> Currently the svn command line client prints out (sometimes, if it's
>> possible) some helpful messages telling the user what to do, e.g., run a
>> cleanup or try an update.
>> The problem I have in TSVN is that in most situations, the error code that's
>> returned is not specific enough. For example, the error code
>> SVN_ERR_CLIENT_NOT_READY_TO_MERGE is not just used if the working copy is
>> out of date and needs updating, but also if the revision of the working copy
>> can not be determined, if a subtree is switched, the wc has local
>> modifications or if it's not 'ancestrally related'.
>> So in TSVN I can not use the error code to offer the user to just run an
>> update and retry the merge, or run cleanup and retry whatever command failed
>> because of that.
>> Could the error baton be extended to contain "action codes" that indicate
>> what action(s) need to be done to (probably) resolve the error?
> Rather than creating yet another piece of error metadata with this "action
> code", would it suffice for the libs to just use unique error code for these
> various situations?

That would be ok too of course. Not quite as easy to handle in
clients, but it would work.
Just make sure the error code itself indicates the action, otherwise I
have to search through the whole sourcecode and find out whether
there's a possible action to execute for the error.


  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net
Received on 2011-05-18 07:33:09 CEST

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

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