Source code control policy

Question

I'm looking for an overview over different source code control policies. I only came across the Main-Line policy and would like to better know others before committing to one with the team.

Can someone provide a link to an overview or even give me some names of policies so I can launch google on it?

Answer 1

No empty commit messages.

Answer 2

The paper "streamed lines: branching patterns for parallel software development" is an excellent discussion on branching patterns such as the "main line" pattern you mention - it lists the options in the form of patterns together with discussion of anti-patterns. One of the authors is Robert Orenstein of Perforce.

Answer 3

We use several practical rules as commit policy in our project. These rules help us to keep every revision in ready-to-deployment state. Our rules are similar to KDE commit policy, posted here: http://techbase.kde.org/Policies/SVN_Commit_Policy. Every commit should be (from higher to lower priority):

• Successfully checked (compiled, tested, reviewed, FxCop'ed, etc.)
• Atomic (should contain only one logical change, f.e. single bugfix, refactoring, etc.)
• Non-redundant (no unused code should be added, do not commit commented code, delete it, do not commit accidentally format changes, etc)
• Correctly and fully commented
• Matched current development phase (for example no refactoring should be allowed in version support branches)
• As small as possible to match previous rules.

We developed a simple tool SvnCommitChecker, witch helps us to check some of these rules before commit to svn. I plan to put it to sourceforge in near future with an article about benefits of keeping good svn change history.

Answer 4

I have had great use of the book Practical Perforce. Though you might not be working with Perforce I think that chapter 7 (How Software Evolves) and chapter 8 (Basic Codeline Management) might be very useful. You might be able to skim them on Google Books.

Perforce also has many great articles on the subject. Software Life-Cycle Modeling writes about policies.
Perforce complete technical documentation.

And, no I'm not working for neither with Perforce.

Good luck, Thomas