Ensure that log messages end with a single newline

[ryandesign (Ryan Carsten Schmidt)]

A recent commit message change of mine returned the following email:

Author: ryandesign@macports.org
Revision: 32288
Property Name: svn:log

@@ -1 +1,3 @@
-pdftk: fail more gracefully if gcj-mp-42 is not present, for example on Leopard PPC as a result of #13553
\ No newline at end of file
+pdftk: fail more gracefully if gcj-mp-42 is not present, for example on Leopard PPC as a result of #13553
+
+This change was a bit wrong in that it broke all build variants other than with_gcc42; this was fixed in r36161.

The previous log message did not end with a newline. This caused useless extra diff info to appear.

It's easy to get into this situation by committing on the command line using svn ci -m "foo" (no newline will be appended to the log message). Alternately, one might do svn ci and let the editor open, and the editor may be configured to automatically end the temporary log message file with a newline.

We should avoid this problem by ensuring in the pre-commit and post-revprop-change hooks that a commit message ends with one and only one newline. As precedent, port lint already complains if a Portfile does not end with (at least) one newline.

Once the hooks are set up, we should also do a one-time fix of all existing revisions' commit messages. Best to turn off the post-revprop-change email notification for the duration of that run so as not to flood people with messages.

We could use the ​log-police.py script provided with Subversion to do all of this. Here is its usage message describing how to use it in the pre-commit hook, in the post-revprop-change hook, and to do the one-time fixup, respectively:

Ensure that log messages end with exactly one newline and no other
whitespace characters.  Use as a pre-commit hook by passing '-t TXN_NAME';
fix up a single revision by passing '-r REV_NUM'; fix up all revisions by
passing '--all-revs'.  (When used as a pre-commit hook, may modify the
svn:log property on the txn.)

[wsiegrist@…]

Thanks for researching this. We should be all cleaned up now with a pre-commit in place.