Doing source control... the right way

Source control, so simple yet so many fail at it. Let's get some "guidelines" to help you out enhance your work with source control and identify problems which may give you trouble on the long run.

Kill CVCS
CVS and Subversion are the MSIE6 of source control. It was fine in the XX century, but really, you deserve better. There are several articles online about why you should kill your CVCS repository and move on. Try a DVCS, you'll know what I'm talking about.


Go nuclear... I mean, atomic.
Atomic basically means small. In the source control world this means: do not commit 300 changes at once. If you find in this situation you're not using source control, you're using a very stupid backup strategy. You're not committing often, you're not writing correct commit messages and you're certainly giving the next guy doing a merge a headache.
The good thing about atomic commits are:

• It makes you think about branching, tagging, merging and commenting.
• Every committed revision gives you a rollback position. So you decide, one hour of lost work or a whole week.
• The risk of a merge nightmare increases dramatically with time.

Commit your code... NOW!
First of all, if it's not in source control, it doesn't exist. So commit often.
There are two reason I see for not committing changes: embarrassing yourself and fill with crap the source control tree. The first one, I've been there, but really, if your code is that stupid, better to learn now. On the second one, repeat after me: "if it's not in source control, it doesn't exist". Your manager won't see that nifty refactoring you have there in your hard drive waiting for the Big Day... the day your hard drive breaks and all your work goes down the drain.

Tags & Branches
Use them damn it!
One of the reasons some people don't commit often is because the're afraid of breaking the build, integration, etc. And they are right. For example, one recurring issue is if you have to work a week or more on certain functionality, and most of the source files you're working on will be "broken" until you're done. Branch it! I have to see the first place where integration is running against active development branches.

Review your changes before committing
I know, I just told you to commit as often as possible, and you should. But only commit stuff which has its place in the DVCS: code. Stuff that shouldn't be in source control:

• Binary files
• Third party libraries 
• Compressed files
• IDE files
• Log files
• Cache files
• Media files
• Documentation

Let's review a little. Binary, compressed, cache, and media files don't get along with source control because they're not text. It’s just wasteful. It’s wasted on the source control machine disk, it’s wasted in bandwidth and additional latency every time you need to send it across the network and it’s sure as hell a waste of your time every time you’ve got to deal with the inevitable conflicts that this practice produces. Log files are text, but it's stupid unless you want to keep track of some specific trace message. IDE files are those files which are generated by your IDE for you, only, not for the whole team. For documentation use a wiki which already provides source control. Stuff that should:

• Code files
• XML files
• CSS files
• SQL files
• Plain text files

Comments
This is easy, right? Here are some examples that you're doing it wrong:

• Some changes
• Fixed
• Fixed [BUG-1302]
• Rev. 1923
• Merge
• ..........

Here, read some more in What is the WORST commit message you have ever authored you'll have fun. Now, adding a message to your commit is like commenting code: think the next guy to read it has an AK-47 and is on the verge of a nervous break down. Actually, know what is really embarrassing? Have your team debugging some issue which is making your company lose money and when they open the source history you don't remember what changeset 896 does because your message is "some shit fixed".


Don't be afraid
If you're not feeling comfortable with using the full feature set of your source control tool, simply make a copy of the repository folder and beat the crap out of it. Branch it, tag it, merge it, branch it again and repeat until you're comfortable. Just remember not to PUSH!


I think this gives us a pretty good start point for a list (I love lists):

• Kill cvs, svn, etc.
• If it’s not in source control, it doesn’t exist.
• Commit early, commit often.
• Review your changes.
• Explain why you committed the code.
• No one cares about your personal settings.
• It's source control, not a backup tool.
• Branch your code.
• Tag your code.