These are the guidelines that ALL Developers with SVN Checkin Access Should follow

1. ALWAYS test a change before committing back to SVN. Even the trivial can break things and should be tested.

2. NEVER check-in code if you know it is going to break things. See rule 3 for alternatives.

3. Large complex changes, rewrites, etc. should be kept in your working directory or done in a temporary branch until reasonable testing efforts indicate it is working and ready to be made available in trunk. Large can be a bit of a judgment call. It may involve a major rewrite, something that touches several different files, or just something that your own judgment says may need a bit more testing and is likely to break things.

4. Try to put useful comments when you checkin. Think CHANGELOG which is what gets generated from here. Comments like "oops" and "thanks joe" don't say much in a change log. Comments like "fixes #1323, thanks joe" will allow you to get back to the bug, but are still not great for a change log. Comments like "fixes #1323, wrong callerid on extensions with display names using <> format" give the reader of a changelog at least something to go by (or just copy the bug description). And then of course, lots more detail about the bug is always welcome if you feel like writing it up.

5. Checking ins can automatically be reflected on Trac. To have your change noted on a ticket, just include one of the following words:

  • addresses
  • re
  • references
  • refs
  • see

To automatically close the ticket, make sure to include one of the following:

  • close
  • closed
  • closes
  • fix
  • fixed
  • fixes

for example: Changed blah and foo to do this or that. Fixes #10 and #12, and refs #12. will close #10 and #12, and add a note to #12.

It is important to try and keep the trunk working, and critical to keep released branches working. Although we make beta and Release Candidate tarballs, there are also early adopters that load svn trunk on their systems. These people are valuable testers in the development process as they help find bugs that we didn't catch despite our efforts from the above rules. If we break trunk too often, then those early adopters will become fewer and fewer which will have a negative impact on the exposure we get between tar ball releases, and betas.