SVN pre-commit hooks with perl tests

[Dominic Mitchell]

On Wed, Jan 11, 2006 at 09:25:39PM -0500, muppet wrote:
> On Jan 11, 2006, at 4:06 PM, Dominic Mitchell wrote:
> >Looking at the pre-commit documentation there, you should be able  
> >to use
> >svnlook --transaction to see what's been checked in.
> 
> This still doesn't help you verify whether the tests succeed.  You  
> either have to pass that information in from the client (which can't  
> be trusted), or run the tests on the server.

You have to run the tests on the server.  Otherwise you'll need a
client-side wrapper.

> Doing a checkout and build in a post-commit is not unthinkable,  
> though for performance reasons it is more desirable to merely  
> schedule a build in the post-commit, in case there are a whole bunch  
> piling up.

This sounds reasonable, although it does lose the immediacy of the
"commit failure due to tests not passing."

It would be nice if the pre-commit script could maintain its own
persistent working copy on the server and update it from the transaction
about to be committed.  But I suspect that this isn't feasible.  Looking
at "svnlook help", you might be able to do "svnlook --transaction foo
diff | patch -p0 -d /some/where/i/checked/out/earlier".

> Doing a checkout, patch, build, and test in a pre-commit, whose  
> return code will be inspected to determine whether the commit may  
> continue, is going to be slow.  You can speed things up by keeping a  
> persistent sandbox and updating, but it will still incur a noticeable  
> lag on the client side ("Why does svn seem to hang whenever i commit?").

Oh yes, that's exactly what I was talking about.  I really should read
the whole email before replying.  :-)

Anyway, running the tests will always incur a significant commit
slowness.  Particularly if it's just fixing a typo in the pod or
something.

Would you be better off looking at something like CruiseControl?[1]

-Dom

[1] http://cruisecontrol.sourceforge.net/