You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Küng <to...@gmail.com> on 2011/05/17 20:54:32 UTC
enhancements for error reporting
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?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: enhancements for error reporting
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
I don't understand why we would need to change the libraries when the
cmdline client can already figure out --- using the same libraries ---
what advice to print.
Stefan Küng wrote on Wed, May 18, 2011 at 07:32:09 +0200:
> On Tue, May 17, 2011 at 22:55, C. Michael Pilato <cm...@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.
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
Re: enhancements for error reporting
Posted by Stefan Küng <to...@gmail.com>.
On Tue, May 17, 2011 at 22:55, C. Michael Pilato <cm...@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.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: enhancements for error reporting
Posted by "C. Michael Pilato" <cm...@collab.net>.
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?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand