SVN pre-commit hooks with perl tests
dom at happygiraffe.net
Thu Jan 12 12:54:42 GMT 2006
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
> 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
Would you be better off looking at something like CruiseControl?
More information about the london.pm