Re: New to subversion, need to find documentation on writing hooks

On 5/20/2012 2:16 PM, Ted Byers wrote:
>
> I have just installed subversion on a Ubuntu VM, and trying to learn
> how to administer both. I have successfully created my first VN
> repository. :-)
>
> Now, I have read through the documentation a couple times, and know
> what hooks are and why they're used, but I am not clear on how to
> write one as the examples I have found so far are written in
> programming languages I don't know (such as Python).
>
> In the first project I am going to put into this repository, I am
> writing a test suite based on Boost's Test library (written in C++).
> What I want to do is write a program that assesses code coverage, so
> that all new code has at least one unit test, and then require that
> the codebase, including all existing and new tests, compile and
> execute successfully; and have a precommit hook that prevents a commit
> unless this test suite program indicates that the tests all passed. I
> have read arguments that recommend against this, claiming it can slow
> down commits, but then I am more concerned about code quality, and
> always having a codebase, which to me includes all tests, that
> compiles and runs properly than I am in the convenience of any
> programmers working on the project. I also write in Perl and
> JavaScript (and not so much anymore in Java or C#), so I will want the
> same requirement on all code in all the languages I routinely use.
>
>
The usual convention is to put the checks in the post-commit hook, then
back out offending changes if any. Otherwise commits can grind to a halt.

I once worked at a company where the pre-commit test suite (not part of
a hook) ran for an hour. We were supposed to ensure that no other
changes had been made to the affected modules before the commit.
However, this would sometimes require several iterations (a dozen
developers and a couple dozen modules under active, though unrelated,
enhancement efforts meant lots of "file has been changed" conflicts at
commit time). Occasionally we simply had to merge, compile, commit, and
then rerun the test suite. (Yes, I would have liked to reduce that
suite to 30 seconds or less, but that was a much larger problem than
what I could change at that company.)

-- 
     David Chapman      dcchapman_at_acm.org
     Chapman Consulting -- San Jose, CA
     Software Development Done Right.
     www.chapman-consulting-sj.com