SVN Commit/Update - Developer Best Practice

Today I have been asked to write a brief process document for a new group of developers working on a website which had only newly been integrated into Subversion. Here are a few of suggestions I will be making.

The command line syntax is very easy, this will commit all the changed files from your working copy.

D:\Test\site>svn commit -m "my great comment"
Sending index.html
Transmitting file data .
Committed revision 66.

Using the Tortoise client you can select individual files to commit, much easier than using the command line client.
Try to make sure your commit comments are as clear and descriptive as possible.

Explain why the change was made, include any bug or change reference that you have. Remember that these notes are not just for your benefit but for the many people who will be looking over the code in the future.

Commit your changes in logical groups.

Each time you commit changes to the repository make them as complete changes. Don’t check in half finished bug fixes or enhancements, unless you really need to. Remember someone could checkout or update to this ‘broken’ version and be disappointed when expected functionality doesn’t work.

Communicate to your team when changing important files.

Each project or website has a certain set of key files, whether it is the default layout for the front page, or a function to pull information from a database. These changes effect everyone else working on the project. They need to be aware of possible issues which may arise from your changes.

Update your working copy before you commit.

It may be a day or a week since you checked out from the repository, in which time others may have committed changes to the files you are editing. Make sure to do an update on your working copy before you commit your changes. Then you wont get any nasty conflict messages.