Automatic hook creation in every new svn repository
Once I had to connect a subversion server to a mantis, so that the commits connected to opened issues would be logged to the corresponding mantis entry after sending them in. This was achieved by using the post-commit hook script. Big positive, it is only linked to a specific repository, every other aspect remains freely upgrade-able, but we have to copy it into each new repo.
In the details I’ll shed light on my thoughts and ideas which led me to the accepted resolution, with which I could automate this step.
We put the post-commit script into the repo created through usvn, and it connects well to mantis. With this it is possible to log all svn commit changes to the appropriate mantis issue.
Any commits sent into a newly created repo remain silent, they just don’t appear at the corresponding issues. This new repository was created through the usvn pages, without any further tampering.
Subversion hooks in detail
Svn let’s you place script into every repo, which will be called on specific events. If I look at a commit on a new version, there are three options:
start-commit pre-commit post-commit
More detailed description can be obtained at Repository Creation and Configuration page.
From those the successful commit was chosen, because that is the point in time when we can be sure, that the new code has arrived in the repository, so we can create the log to the connected bug.
One of the positives becomes a negative in our case. As all the repos can have their own specific scriptsets, we do not have any means to create a global post-commit script, which will be called for the commit event on all repos. We have to make efforts to copy the script into each new database ourselves.
Variations on a subject
My third idea seemed to be manageable and well-formed at the same time. I will enlighten the first two, so you can have an idea, what has led me to the accepted one.
Modifying the template for new repositories
I first had the idea to modify the template from which svnadmin copies the structure for a new database, so I’ll only have to copy my script to one place, and svnadmin will distribute it for me every time a new repo is created. Mostly like /etc/skel is working for new users under linux.
I couldn’t find this skeleton using a filesystem-search, so I went to the source code of svn, assuming that I could find the path therein. I have found something far more interesting.
There is a function in the 284th line of libsvn_repos/repos.c, which is responsible for creating the hooks directory and its contents. The code has stunned me. Source code has all the files contents for the templates, so this is why they cannot be found in the fs.
Modifying the source code and recompiling the svn was out of question, because that would break the update-chain, and I would have had the burden to re-create my modifications in every svn update.
*nix-based systems have a built-in functionality for running programs at predefined schedules. My second idea was based on these functionality. In theory: I could check the directory holding all the repositories in certain periods, and if there is any new repo copy our post-commit script into it.
The selection of a decent timespan could cause problems.
- what timespan is suitable to check for new repos?
- as this event is only rare, the process could unnecessary consume too much resources
It could have been a small nightmare selecting a proper timespan, which is also responsive as well as not too much resource-consuming in between creation of new repos.
From that I had the thought, linux kernels have an interesting feature: inotify. In short: it sends out signals whenever an inode (file-descriptor) changes, informing the applications which have subscribed for that event. Fortunately we do not have to write any kernel modules or daemons for subscribing to these event, some others have already done so. The package is called, at least in ubuntu/debian incron. Installing can be done using the already known methods, this is outside the scope of this post.
After setup it meets all our expectations:
- is notified about creation of a new repo instantly
- does not use any resources between creations
- all parts of the system remain updateable (assumed, the directory-structure of svn remains the same, and it still supports post-commit hooks the same way)
Pages: 1 2