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

RE: Custom error messages

From: Oren Eini (Murphy & Associates) <v-orene_at_microsoft.com>
Date: Fri, 7 Mar 2008 11:03:33 -0800

> -----Original Message-----
> From: Karl Fogel [mailto:kfogel_at_red-bean.com]
> Sent: Friday, March 07, 2008 11:00 AM
> To: Oren Eini (Murphy & Associates)
> Cc: dev_at_subversion.tigris.org
> Subject: Re: Custom error messages
>
>
> > errcode match the standard SVN error codes, and on some cases 16006
> > (revision doesn't exist), the client will display the message from
> the
> > server. In other cases, it appears to use just the errcode number and
> > internal resource for that.
>
> Now this does sound like it might be a bug in the Subversion client, if
> it's behaving differently on receiving the same error (in which case
> this list is, of course, the right place!) But we'll need a full
> reproduction recipe as described in
>
> http://subversion.tigris.org/bugs.html
>
> ...if you have time to write one. Thanks!

The problem is that I don't think that this is a bug.
The usage of the server message is consistent when you are getting certain error messages.
As an example, for errcode 160006 the client will show the error from the server.
For 160024 errcode it will not.
I would assume that this relates to messages that requires parameters or not.
The 160006 is the revision does not exists, and it needs the information from the server.
For 160024, there is no need for additional information from the server, so it probably just use an internal resource instead of using the server message.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-07 20:03:54 CET

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.