Nothing more embarassing than committing awesome code with a parse error. Quick
php -l
will take care of that. But if your repository has files under many directories and you’ve made changes to many files, it can be a pain to php -l all of them as you can only pass one file to “php -l” at a time.
Here’s a quick shortcut:
svn stat | grep ‘php’ | awk ‘{print “php -l ” $2}’ | sh
“svn stat” will list all files that have been changed. The grep will filter the result and only show PHP files. The awk command takes the 2nd column of the output and does “php -l” on every file in that column.
Granted, this is convenient but painful to type and error prone. Solution: save it in a file svnlint.sh, then add an alias:
alias svnlint=’sh ~/svnlint.sh’
At this point, before every:
svn commit
do:
svnlint
Your PHP files will be free of syntax errors (so you can focus on those “real” bugs…)
Dave
on May 15th, 2007
@ 1:55 pm:
If you wanted to be mean you could setup a pre-commit handler to run something like what you’ve specified, and reject commits that don’t compile!
Of course, things might not work out 100%. I’ve not tried it!
Keith Casey
on Jul 9th, 2007
@ 7:47 am:
Some people are tying CodeSniffer into their commits too: http://blogs.lib.ncsu.edu/page/web?entry=codesniffer_pear_package
I’ve integrated it into my “build” process in Eclipse and will add it to my Phing script shortly.
Kevin Cox
on Jul 17th, 2007
@ 6:45 pm:
I put the following in ~/bin/svnlint (don’t forget to chmod +x it):
#!/bin/sh
svn stat | egrep ‘(php)|(phtml)’ | awk ‘{print “php -l ” $2}’ | sh
You can keep going adding extensions to the regex, if you like…
Braden
on Sep 7th, 2007
@ 6:56 pm:
Fantastic. I knew I needed to use awk somehow, but couldn’t get it right. Thanks.
Braden
on Sep 7th, 2007
@ 7:00 pm:
And to continue on Kevin’s path, ‘\.(php)|(phtml)$’ seems sensible.