[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: Greg Stein <gstein_at_gmail.com>
Date: Fri, 27 Apr 2012 12:10:03 -0400

On Fri, Apr 27, 2012 at 11:20, Philip Martin <philip.martin_at_wandisco.com> wrote:
> 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.

WELL aware of that fact. I was simply giving a data point for how the
path was used.

What's your point?

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

And other RA layers do not.

-g
Received on 2012-04-27 18:10:37 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.