Do you have any commit policies?

Question

My boss announced yesterday a new commit policies for checkins into the repository. This policies are valid for commits into head/trunk and branches.
A commit message must have the following items:

• Reason (Bug ID,Project ID, or non functional change)
• Name of the reviewer

After the commit we also have to create a change blog entry in our CMS.

I'm not a big fan of this commit policies, because I don't normally need a reviewer when I am doing new or experimental stuff in a non-productive-branch.

Do you have any commit policies do you have to follow?

I think it is a good idea to change the productive-branch only due to a Bug Report, but commits into the development branches should be less restrictive.

Answer 1

Commit early and commit often.

We actually use /trunk as development and tags to branch different releases. Only structural intrusive changes go in /branches.

We actively use tags for production and acceptation releases, so we can go back in time easily. Anything committed in the trunk should only have a message describing what the commit changed or added briefly.

I'm not a big fan of using the message space to link with Bug ID's it still requires a lookup for the ID in which case you could also look it up in the bug tracking software and close it there, which to me is about the same effort.

Not to say i dont like any svn integration: - We use more goodness of automated nant scripts to make releases which branches them in /tags - svn props actually store our version numbers :p. - hook scripts for email notification and message logging (great for copy pasting release notes).

Answer 2

We have a number of policies, which are enforced via an in-house plug-in to Visual Studio. We check that code compiles and that unit tests have be run successfully. At the moment we also check code coverage and issue warnings for code which doesn't have enough tests. We also do various consistency checks and verify that an appropriate task is present in our change management system in order to provide traceability for all changes.

The advantage of tool support is great, as it is not really up to people to respect the policies, but obviously there's a drawback as well as these checks take time to run. However, with many developers it is hard to enforce standards without proper tool support.

Answer 3

A reviewer seems pointless for the reasons you mentioned, because not everything needs to be reviewed by others.

In the past the only commit policy we had (where I used to work) was to include a comment indicating what you changed and why, but that's more common sense than anything else.