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

Re: [PATCH] show hook errors on client side

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2002-09-08 12:45:29 CEST

Branko ÄŒibej <brane@xbc.nu> writes:

> Philip Martin wrote:
>
> >Kevin Pilch-Bisson <kevin@pilch-bisson.net> writes:
> >
> >
>
> >> Right, subversion needs to have some mechanism to output warnings
> >> basically. A way for a lib to call back to the client with the
> >> warning, and then continue it's operation.
>
> >>
>
> >
> >Gustavo Niemeyer made the same point elsewhere in this thread. Note
> >that in this case the "lib" is part of httpd, and the client can be a
> >separate process on a remote machine. So it's not a conventional
> >callback.
> >
> I think what we need is a way to send a multistatus response. I'm sure
> mod_dav(_svn) can send those, becasue I've seen them coming from
> there; and neon can handle them.
>
>
> The only question, then, is where to generate such a beastie.

Yes, there are really two problems here. First, the commit has to
report the successful repository operation, including the new revision
etc., as well as the failure of the post-commit hook. Multistatus may
be the correct solution here, Greg also mentioned multistatus in issue
443. Second, the client needs a way to report the hook failure while
continuing to do post-commit processing.

It occurs to me that the new warning callback could simply be
implemented as part of the existing notify callback. If we add
another symbol to the svn_wc_notify_action_t enum, something like
svn_wc_notify_warning, and add another argument (probably an
svn_error_t*) to the notify callback to pass the warning data, then we
have all we need. Rather than simply extending the notify callback
argument list, it may be better to introduce a union, so that only
those items relevant to a particular action need to be set.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 8 12:46:37 2002

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.