Subversion User Best Practices

Policy

We use an Unstable Trunk policy.

• Most development happens in the trunk (Live web site).
• Don't break the trunk!
• Bugs are found - by our users if we miss them! - and fixed quickly.

Alternative: do work on a branch, and later merge changes.

• Means more merging.
• A lot more merging.
• Easier to ignore what other developers are doing :-(
• Always-Branch policy typically used in a heavily centralized situation where a supervisor OKs each coder's work (branch) before it is merged.

I think we might branch if we were going to change the whole site, e.g. PHP->Java, or a fundamental change to the way we INCLUDE navbars etc.

Commits

• Commits are good; commit each discrete thing you do. "Commit as soon as your changes makes a logical unit. ... To make it simple: your SVN comments shouldn’t explain that you did more than one thing. If your SVN comment looks like “Fixing bugs #1234 and #1235″ or “Fixing bug #4321 and correcting typo in debug string” then you should’ve used two commits." - Salvatore Iovene (http://www.iovene.com/5-svn-best-practices/)
• Don't commit to "save your work" at the end of the day.

Comments

Any communication tool becomes useless if you send garbage through it.
So you need to make sure that people can understand your changes.

• Each change should be self-contained.
• The log message should contain useful information.


• What did you change.
• Why did you change it.
• Include filenames touched and functions modified.
• Make it possible to grep the logs later when looking for something.