C. Michael Pilato wrote on Tue, Dec 21, 2010 at 14:40:01 -0500: > On 12/21/2010 02:08 PM, Daniel Shahaf wrote: > > Blair Zajac wrote on Tue, Dec 21, 2010 at 10:55:37 -0800: > >> On 12/21/10 10:40 AM, Daniel Shahaf wrote: > >>> Blair Zajac wrote on Tue, Dec 21, 2010 at 10:16:56 -0800: > >>>> 4) In svn_repos_fs_commit_txn(), which order should errors be composed? > >>>> svn_fs_commit_txn()'s error as the parent followed by the > >>>> SVN_ERR_REPOS_POST_COMMIT_HOOK_FAILED error as a child? This seems to be > >>>> the standard ordering of chained errors. On the other hand, it makes it > >>>> harder to find a post-commit script error. > >>> > >>> Actually, it will make it impossible to detect post-commit errors over > >>> ra_dav, since that RA layer marshals only the outermost error code in an > >>> error chain. > >> > >> ra_dav already checks for SVN_ERR_REPOS_POST_COMMIT_HOOK_FAILED, it could > >> use svn_error_has_cause() to find it. > > > > How can it do that if only the topmost error code is marshalled? > > > > I first discovered that ra_dav only marshals the outermost error code > > (and its error message, but nothing else of the chain) when I worked on > > the atomic-revprops branch. In dev@ archives there should be some > > discussions of how error chain marshalling might be implemented, but > > eventually I solved the problem differently for that branch (by using > > another error-signalling mechanism). > > > > ra_svn marshals full error chains. > > Can we fix this? Can we introduce a new error code > SVN_ERR_RA_DAV_ERROR_CHAIN which means, "the descriptive message of this > error contains a skel which, when parsed, carries a whole chain of real > errors? Then we have the client indicate at capabilities-exchange time that > it can handle that kind of return. >
+0. (not a +1 because I don't know the ra_dav protocol well enough) Instead of skels, we could re-use svn_ra_svn_write_cmd_failure() and svn_ra_svn__handle_failure_status(), though. > -- > C. Michael Pilato <cmpil...@collab.net> > CollabNet <> www.collab.net <> Distributed Development On Demand >
