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

Re: svn commit: r1330058 - in /subversion/trunk/subversion: include/svn_error_codes.h include/svn_fs.h libsvn_fs/editor.c libsvn_repos/commit.c

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 27 Apr 2012 16:20:22 +0100

Greg Stein <gstein_at_gmail.com> writes:

> On Wed, Apr 25, 2012 at 16:43, Philip Martin <philip.martin_at_wandisco.com> wrote:
>> Perhaps we should keep the error and toss the path?
>
> mod_dav_svn uses that path to construct a "nice" error message based
> on the context of the commit.

mod_dav_svn isn't the only user of this API.

>> So currently reporting "conflict on path 'foo'" is probably sufficient
>> but it's odd to limit ourselves.  We have an error reporting mechanism
>> why would we choose not to use it?
>
> Well... we return that conflict_path so that callers can make
> nicer/contextual error messages with the path. We don't transfer the
> whole chain over the wire, so if the path is on the inner error (say,
> if we just wrapped context and relied on the path to be in the inner
> error), then the user would never see the path.
>
> If we could/would marshal the whole error chain, then yes: we could
> rely on our error reporting mechanism. But we don't, so we can't.

svnserve returns an error chain, see svn_ra_svn_write_cmd_failure.

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Received on 2012-04-27 17:21:02 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.