The Branch-When-Needed system
(This is the system used by the Subversion project.)
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.
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.
Best Practices (I): Committing
Commit often
Commit logical changesets
Use commit messages for Changelog (+ = feature added, - = bug fixed, # = minor change, ...)
Always do Update-Resolve-Commit cycle
Don't break the tree (else{ feel_embarassed(); } )