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.
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).