How to send stdout to the user when running SVN pre-commit hook

Question

I have a pre-commit hook for SVN which run error-checker program and aborts commit in case of problems. stderr is redirected to the user initiating commit in case of problems. But I would like to send user output from the error-checker program even if no problems were found, so that the user is notified that error-checker ran and found no problems. How to do it with SVN pre-commit hook?

Answer 1

You must map the username to an email address somehow. Then you can collect the output in a file and mail it to the committer.

Answer 2

See this or this or this for tutorials/examples.

Answer 3

Subversion hooks eat their STDOUT. Once the script is run, there is no STDOUT. You can't even have the pre-commit script send STDOUT to another process.

However inside the pre-commit hook, STDOUT still exists and can still be redirected. For example, my hook consists of a shell script consisting of several lines of Unix command line utilities. Each command line utility has a STDIN and a STDOUT, and I can pipe from one to the other. But, once that hook script finishes executing, there is no STDOUT.

The other thing is that there is no way to communicate STDOUT via the hook paradigm. Subversion doesn't provide any sort of communications link. There is a link for STDERR, but only if the hook itself fails. This being a pre-commit hook, I doubt you purposely want to fail this hook just to give the user the report.

What you can do is use other methods of notification. Some people suggested email. You could run a post-commit script to generate the report and email that report based upon the user's email address. I would not do this as a pre-commit trigger because you don't want the transaction to fail because the report didn't work.

Some people suggested that you can map the user who did the commit with an email address and email the user. I would not do this because the users will simply ignore the email. They already get dozens if not hundreds of emails from various processes alerting them to this or that.

What I would recommend is to use a product like Hudson to do continuous builds, and have this report generated by Hudson and posted on the build page Hudson generates. This way, a developer can go back and examine the report. In fact, Hudson already has various plugins that do error checking and produces all sorts of nice reports and graphs (usually working with findbugs or other projects like that).

One of the more interesting plugins is a game that awards points for successful builds, fixing bugs and warnings, etc. It presents a leader board, so developers can compare their score to other developers. I never used it, but some people on the Hudson user group say that the developers get very competitive over their scores.