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

Re: Returning Warnings from Subversion Hooks

From: Toby Thain <toby_at_telegraphics.com.au>
Date: Sat, 29 Nov 2008 16:22:30 -0500

On 29-Nov-08, at 2:58 PM, Ryan Schmidt wrote:

>
> On Nov 28, 2008, at 14:01, Hutchinson, Greg wrote:
>
>> Sometimes it would be useful to return a warning in a post-commit-
>> hook. (The class you checked in contains raw types, you should
>> consider fixing.)
>> However, it is our understanding that if we write anything to
>> Stderr it will not make it back to the client unless the hook
>> returns non-zero. Is this correct?
>
> That is correct, so to issue non-fatal warnings from your post-
> commit hook, you must send it via another means, for example by email.

Yes... I've set up several systems where commits were announced by
Jabber*.

It would be easy to send warnings this way. A multi-user chat would
then act as a form of public shaming. :)

--Toby

* - I wrote this bot & hooks for the purpose:
http://www.telegraphics.com.au/svn/jabberbots/trunk/

>
> To give an example, in the MacPorts project, we run a script in
> post-commit to check the syntax of committed files, and if they
> don't pass, we send an email to the committer with the syntax
> checker report.
>
> http://trac.macports.org/browser/trunk/base/portmgr/jobs/
> portfile_lint.pl
>
>> and does anyone else see this as a useful feature?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-11-29 22:22:54 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.