In short - I am using free SVN hosting service and I want to integrate JIRA with SVN. However I want to implement pre-commit hook for SVN to validate commit comments against issues in JIRA and deny such in proper circumstances. I don't have direct access to SVN server ofc, so I am wondering is it possible to configure SVN on another maschine to act like "proxy". Commit flow would be something like:
1) User -> commit to proxy -> validation ok -> commit to external repository
2) User -> commit to proxy -> commit validation failed -> return to user with error message
Is this got some to do with so called "externals" (whatever that is)?
Take a look at Jenkins. It's light and easy to configure. What it can do is run a task after each commit. It can compile code, run unit tests, deploy, and can do most of the tasks which you think require post-commit and pre-commit hooks.
I am very leery about rejecting a commit if the Jira issue is incorrectly attributed. What happens is that changes are snuck in under other tickets, or a faux ticket is generated and all commits happen against that. I was at a bank where you couldn't commit a change unless there was a Jira ticket, that ticket was in the open state, and it was assigned to you. What happened is that known bugs discovered in the code were not fixed, unit tests couldn't be made to work, and that when developers fixed stuff, they simply applied it against tickets they knew were open, and had nothing to do with the fix. The information in Jira became meaningless.
The first thing I did was remove that pre-commit trigger and added in Jenkins as part of the development process. Suddenly, commits were faster, and developers started to handle issues they discovered on their own. The number of unit testing increased, and code improved as developers made sure it could pass new unit testing. More surprisingly, developers started adding the Jira ticket information, and give more detailed commit messages due to Jenkins.
Jenkins is normally setup to do a build after each commit. The build may include other things such as linting your code, running unit tests, building the documentation, and reporting (with graphs) on any issue found in the commit. Jenkins can even deploy the code and run functional tests too.
However, each build shows the commit message. If there's a Jira ticket in the commit message, there's a link to that Jira ticket. Even better, Jenkins adds a comment to a Jira ticket that this bug was handled in a particular Jenkins build (with a link back to that build).
Now, instead of merely being a development tool, Jenkins became a QA tool too. QA would find an issue that is marked fixed in Jira, see the Jenkins build where that ticket was fixed, and then test that particular build. (Another feature of Jenkins: It can store the deployable artifacts in each build.). QA could reopen the issue if required or report on new bugs discovered. Instead of QA coming in at the very end of a sprint (or release), QA was actively following developers. Bugs could be detected the day after a developer wrote them, and fixed the next day.
The project managers also found Jenkins and Jira a useful combination. They could now say exactly what build would be deployed to production. Builds were marked as they were tested in various environments. No more a build being approved in UAT, and developers sneaking in a few code changes that were never tested until production.
Because of the pressure from QA and project managers, development managers pushed their developers to add in good commit messages and add in the required Jira tickets. Additionally, the development managers also found the information in Jenkins useful. The commit message could be viewed not in isolation, but against a particular build, a set of unit tests, and features. Even the developers themselves found this information useful. It was one of the first times developers bothered to look at the commit messages. Before, commit messages were meaningless. Developers mainly put in meaningless Jira information and commit messages like "fixed bugs". Now, the commit messages were meaningful, developers were able to use them to track changes.
In the end, we got rid of the pre-commit hook, and Jira ticket information actually improved in the commit messages. It improved because we changed the culture of the organization. This is how good CM happens. Tools no longer get in the way of the job. Instead, they become important to your job. Everyone saw the quality of the software improved, and became advocates of the process.
There is ways of having proxy Subversion servers. Wandisco offers what they call Subversion Multisite which allows you to have proxy Subversion servers located all over the world. However, these are mainly to allow remote developers a local Subversion repository. Wandisco makes sure all commits happen against all repositories.
The problem is you want your proxy to prevent commits in the main Subversion repository. This isn't possible -- unless you deploy pre-commit hooks to force the main repository to wait until the proxies decide whether or not to allow a commit to take place -- which you can't do. Otherwise, your proxies will not have the commits that are in your main repository.
Besides, why bother with the proxy? If you can setup proxies, why not simply use the proxies as your main Subversion server?
However, you can setup a Jenkins server in an hour, and get true integration between Jenkins, Jira, and your Subversion repository. You play your cards right, and you will not only find this solution good enough, but better than depending upon a pre-commit hook.
If you treat your developers as a bunch of whiney grade schoolers who must be carefully watched so they don't break the rules, they'll act that way. If you treat your developers like highly qualified professionals, they'll act that way.