SVN (subversion) hooks are a little more complicated than Git hooks; they will depend upon how your system is con gured to a degree. The hooks are stored in your SVN repository in a sub folder called hooks. As with Git, they need to have speci c names (a full list of which is available in the SVN manual). For our purposes we are only interested in the pre-commit hook, so let's start off with a *nix-based environment. First of all we need to create a le called pre-commit, and then we will populate it with:
#!/usr/bin/env bash mvn clean install
As you can see it looks identical to the Git hook script; however there may be problems. SVN hooks are run against an empty environment, so if you are using an environment variable to make mvn a recognized command, things may not work. If thereisasymlinkin/usr/bin or /usr/local/bin/,youshouldbe ne;ifnot,you will probably need to specify the absolute le path location to the mvn command.
Now we need to also make this hook work for people using Windows. It will be very similar, but this time the le needs to be called pre-commit.bat; this is because SVN looks for different les in different operating systems.
mvn clean install
Again it's pretty similar; we just don't need to have a Bash shebang. Windows suffers from the same empty environment problems so again you will probably have to supply an absolute le path to your mvn install command. Let's hope that everybody developing in Windows has installed Maven to the same place.
It is worth bearing in mind that hooks like this are not infallible; if you have some local changes on your machine that are not committed the tests may pass, but that code will not be pushed to the central code repository, resulting in a build failure if anybody else tries to run it. As with all things, this is not a silver bullet, but it can certainly help.
We have now made sure that our tests run before the code is pushed to our central code repository so we should have caught the vast majority of errors; however, things are still not perfect. It's possible that one of the developers made a code change that they forgot to commit. In this case the tests will run on their local machine and pass, but an important le that makes this change work will be missing from the source control. This is one of the causes of works on my machine problems.