SVN best-practices - working in a team

I'm starting out with SVN. I know the basic commands and understand the base principles. I was wondering if anyone has any tips or best practices for working with Subversion in a team environment.

I can see the benefit of adding reasonably verbose messages when committing code, but are there other things I should bear in mind?

Thanks for all the great answers - they've helped a lot.

Solution 1:

Encourage frequent commits. Teammates new to version control may feel like they need to keep the code out of the repository until "it works right". Teach everyone to commit early and often to find issues as soon as possible. Instead of holding code 'till it works, propose that your teammates create branches for feature that might break trunk. That leads to...

Establish a branching and tagging practice. In addition to branches for features, encourage your teammates to use branches for large-bug fixes. Tag major bug fixes at the beginning and end of the work. Maintain tags (and possibly branches) for production/qa releases.

Establish a policy for trunk and stick to it. One example might be, "trunk must always build without errors." or "trunk must always pass all unit tests". Any work that can't yet meet the standards of trunk must be done in a branch.

Solution 2:

Do not commit formatting changes with code changes

If you want to restructure a giant file's whitespace (Control+K+D), fine. Commit the formatting change separately from the actual logical change. Same goes if you want to move functions around in files. Commit the moving separately from the actual editing.

Solution 3:

One of the key concepts I always stick by is to commit related code changes together. The corollary is do not commit unrelated code changes in the same commit. This means don't fix 2 bugs in one commit (unless it's the same fix), and don't commit half a bug fix in each of 2 commits. Also, if I need to add some new enhancement or something to an unrelated part of the system that I then need for some other work, I commit the enhancement separately (and first). The idea is that any change anyone might conceivably want to have on its own (or roll back on its own) should be a separate commit. It will save you tons of headaches when it comes time to do merges or to roll back broken features.