What are some common and/or useful pre-commit hooks for SVN?
相关问题
- How can I set the SVN password with Emacs 23.1 bui
- Outlook Object Model - Hooking to the Conversation
- If statements in .htaccess files, to enable passwo
- How to get a slug name for a page without creating
- SVN+SSH checkout over VPN using tortoise SVN, Smar
相关文章
- What is the tortoisehg gui equivalent of doing “hg
- How to use Mercurial from Visual Studio 2010?
- SSIS solution on GIT?
- Is it possible to do a “destroy history” in TFS?
- Is there a version control system abstraction for
- Intermittent “SVNException: svn: E175002: Connecti
- IntelliJ Subversion Authentication Required Dialog
- TortoiseHG and hgsubversion (Windows): “no module
We use a pre-commit and post-commit hook combo to automatically update bugzilla with the associated entry from the svn commit.
We use a second (pre-commit) hook to ensure that the appropriate svn:eol-style and svn:keywords properties are set on a file before it is added to the repostitory.
We have a third (post-commit) hook to kick off a build and mail the results if the build is broken, and to inform everyone when the build has been fixed again.
We have a fourth (post-commit) hook to kick off svn replication, to ensure that the offsite replication is as up to date as possible.
Unfortunately, I cannot post the source to these, but, except for the Bugzilla integration, they are easy enough to implement, and Hudson is probably a better choice for continuous integration.
For bugzilla integration, I would suggest looking at scmbug.
I check for case collision (stupid windows) and also require-mergeinfo.pl to ensure that the client is at least 1.5 - that way svn:mergeinfo will always be set
In the company I currently work on, this is checked:
I guess that's it.
I like the idea of checking if the commit is associated with a ticket; it actually makes a lot of sense to me.
That a user has actually entered a comment on the commit message, and that it contains a particular issue number to track.
A great commit hook we have at on our archive is to check all .VCPROJ (or .CSPROJ) visual studio projects to make sure the output directories weren't changed to anything local (commonly used for debugging).
These problems will compile properly but still break the build because of missing executables.