Critical for teams

If your team is larger than one, source code management is essential. It will allow your team to work together more quickly, with much less "stay out of this; I'm working on it", and much less "I'm not sure what this person was doing here". Hands-down, the successful implementation of SCM will be the biggest win for your team's coordination and performance.

Helpful for code archaeology

When faced with old code of your own, or someone else's code, seeing the log messages and way it was built is often incredibly helpful in finding bugs and maintenance.

Branches

Often, you'll work for a day or two on a new idea, only to figure out that it isn't working out, you've screwed up, and you can't remember all the billions of things you changed while on a tear to try out this new idea. This is exactly what branches in a version control system are meant to manage.

Learn how to use branches for your VC system. They're easier than you think, especially in Subversion.

Subversion

• Similar to CVS, but redesigned from ground-up
• Commits are for an entire changeset, not just files
• Easier to understand relationship of commits
• Sane Python API for utilities

Subversion in 1 Minute

• svnadmin create /var/lib/svn
• Create your product structure and files
• svn import *url to repository*
• Excellent book on Subversion published by O'Reilly - based on the online book.

SCM Not Just for Coders

• Graphic/shell front ends for Windows, Linux, and OS X
• Simple enough for designers and scripters to use
• Easy to sell — "You don't have to worry"

At first, the task of having non-developers use your version control system seems daunting. I've found, however, the non-developers can love it when they realize they can easily work off files on their computer and sync it with the server, and they understand that they don't have to "worry" about mistakes. It's all in how you sell this idea.

Best Practices for SCM

• Log messages are your friend
• So don't treat them like your enemy:

Refer to collector items in messages

It's good to pick a simple, standard syntax for this. I frequently use the phrase "Collector #123", and can build web tools that allow you to jump right to that bug to see the details of what you were tryin to fix. This helps close the loop on why you were making these changes in the first place.

Focus on why, not what

Of course you were editing login_form. We can see that. Why, though, did you make those changes? What was broken? What client request does this address? This is the information you'll want later. Explanations of what you're doing should be in the code as comments, anyway.

Check in "pristine" copy as first copy

If you want to customize Plone's login_form, for example, don't copy it to your site product directory and immediately start hacking on it. Instead, copy it to your directory, check it in right then, in its pristine form, then start hacking away. Now, you've solved two problems: (a) it's trivial for you to diff revision 1 and revision 2 of this file to find out why you were customizing it in the first place, and (b) when Plone is upgraded and there are changes to the shipped login_form, it's much easier to incorporate those, since you know exactly how login_form looked when you started, without having to dig around and find that version.

These things take only a tiny bit of discipline — and they really pay off later. It makes it much easier to understand why you customized a Plone skin two months back.