General Rules

When you commit a change to the repository, make sure your change reflects a single purpose: the fixing of a specific bug, the addition of a new feature, or some particular task. Your commit will create a new revision number which can forever be used as a "name" for the change. You can mention this revision number in bug databases, or use it as an argument to svn merge should you want to undo the change or port it to another branch.

We use a "Branch-When-Needed" system - 

    * Users commit their day-to-day work on /trunk.
    * Rule #1: /trunk must compile and pass regression tests at all times. Committers who violate this rule are publically humiliated and flogged.
    * Rule #2: a single commit (changeset) must not be so large so as to discourage peer-review.
    * Rule #3: if rules #1 and #2 come into conflict (i.e. it's impossible to make a series of small commits without disrupting the trunk), then the user should create a branch and commit a series of smaller changesets there. This allows peer-review without disrupting the stability of /trunk.