-> Note, however, rejecting "empty" changelogs doesnt actually help much.
-> (I often see the changelog entry of "notes in code", for example)
That's a training issue, and lessons will be learnt once they
have to trace back through log messages looking for a change.
-> Also note, once again, pre-commit hooks are not applied until after
-> all data has been transmitted. It can be annoying to transmit a
-> huge entry only to have it rejected because of a commit message problem.
-> I'd recommend instead having a post-commit which checks the
-> message and sends an e-mail asking for a better message if
-> it's empty.
If you're going to recommend that approach** then it might be
an idea to mention that the pre-revprop-change hook will have to
be implemented as well as the post-commit hook, otherwise if
users want to go back and change a revision property (svn:log)
they won't be able to. TortoiseSVN and Subclipse make it easy
to change a log message, you just have to make it possible.
** Unless you've got limited bandwidth to the repository (e.g.
dialup internet access) I wouldn't recommend post-commit reminders,
simply because if people are committing often then the changesets
should tend to be smaller, and the log messages more meaningful.
The pre-commit rejection message need not just look for empty messages,
you could add more tests if you like, but really it's a training
issue.
It's too easy to read an email and say I'll do it later when I
have time, whereas rejection mandates an action and helps get
people into the habbit of entering a log message, at the time
when details should be fresh in their mind.
peace
si
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 22 06:55:11 2005