On Thu, 20 Oct 2005, Madan U Sreenivasan wrote:
> On Thu, 2005-10-20 at 03:10, Philip Martin wrote:
> > Madan U Sreenivasan <madan@collab.net> writes:
> >
> > > --- subversion/mod_dav_svn/version.c (revision 16776)
> > > +++ subversion/mod_dav_svn/version.c (working copy)
> > > @@ -1614,6 +1614,7 @@
> > > svn_fs_txn_t *txn;
> > > const char *conflict;
> > > svn_error_t *serr;
> > > + char *post_commit_err = NULL;
> > > svn_revnum_t new_rev;
> > > apr_hash_t *locks;
> > > svn_boolean_t disable_merge_response = FALSE;
> > > @@ -1694,7 +1695,11 @@
> > > return dav_svn_convert_err(serr, HTTP_CONFLICT, msg, pool);
> > > }
> > > else if (serr)
> > > - svn_error_clear(serr);
> > > + {
> > > + if (serr->child->message)
> > > + post_commit_err = apr_pstrdup (pool, serr->child->message);
> >
> > are building detailed knowledge of the structure of the repository
> > error chain into mod_dav_svn. I'm not quite sure what you are trying
> > to do, but if you are looking for a particular error then perhaps you
> > should iterate through the list checking apr_err?
> theres only one level of error message, in this case.. I think iterating
> would be overkill...
You're missing the main point that you're building this assumption about
how libsvn_repos reports errors into mod_dav_svn. That's not guaranteed.
If you want to provide the post-commit hook error back from an error with
a specific error code as Philip suggests, that's fine, but you can't
just assume that the next error in the chain is what it is today; it's an
implementation detail of libsvn_repos.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 20 11:01:13 2005