[LLVMdev] svn pre-commit hook: help needed

Elijah Epifanov elijah.epifanov at gmail.com
Wed Feb 18 12:25:47 PST 2009


> On Feb 18, 2009, at 1:41 AM, Julien Lerouge wrote:
>
> > Yet another _fun_ way of doing this is to setup a buildbot slave just
> > for that. The slave can fix minor stuff like tabs and trailing
> > whitespaces on its own (checking the changes back in), and yell for
> > things like 80-col violations and whatnot where the changes would
> > not be
> > so trivial.
>
> If you're going to change anything then this is the best alternative,
> otherwise I can live with status quo.
>
> Do not reject commit just because of formatting issues. It can have
> serious -ve impact on productivity.
>
> To folks who prefers to reject commits due to formatting errors -- You
> already rely on a some kind of "tool" to make your day to day life
> easier. [ Most likely you've your editor automatically replacing tabs
> into spaces. Your terminal window is only 80 col. wide or your editor
> is displaying a vertical line to warn you about 80 col. and so
> on... ]. The  build bot suggested by Julien is yet another "tool" that
> accomplishes the same.  One the slave bot can use clang static
> analyzer ... :)
>
> -
> Devang

1. buildbot doing reformats is worse than not taking care of formatting at all.
2. modifying svn transactions is a *crime*
 (the same effect as making a whole [every field, every function] c++ program
 const-qualified, and using const_cast everywhere to live with it)
3. pre-commit hook rejecting not properly formatted commits *is* a good thing.

We use it at work and it saves tens or even (few) hundreds manhours per
month when merging commits between different releases while spending
less than 1 minute per commit (formatter run per project takes about 1 min).

At llvm, code style policy probably will not save that much, because you don't
have to maintain 3-5 branches (trunk, testing, production + approx 2 large
branches for integration with other projects or major features not fitting in
release cycle).

And I strongly suggest you to use very strict policy - this helps merging a lot.

Hope that helps (our [depersonalized] pre-commit hook included)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pre-commit-example.sh
Type: application/x-sh
Size: 3318 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090218/c1e73bac/attachment.sh>


More information about the llvm-dev mailing list