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

These two are basically the same:
Version Control for Multiple Agile Teams
Configuration Management Branching Strategy

We are using this strategy to make the trunk stable and enable developers do whatever they need on their branches.

There is some problem with Subversion since it can't handle Cyclic merges but it can worked around by deleting development branch after each reintegration back to the trunk (irrelevant for other version control systems)

Answer 2

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 3

Commit per-change instead of per-file.

This has following advantages:

• You can later see why this single line has been changed in this exact file (aha, this was bugfix for bug #123). If you commit per-file then commit messages tend to describe changes done in file - which you can see with diff anyway. If you commit per-change then commit messages tend to explain why the change has been done in the first place.
• It is much easier to revert or merge changes/bugfixes.
• It helps to organize your work better as you clearly focus on a single bug/feature/change you are working. You commit when you are done.

Some people think this policy produces more commits but from my experience you get less commits after all. For example, you are doing refactoring which affects 50 files. After refactoring you have a single commit with a message "Refactored xyz subsystem.".

For bigger changes you should consider dev-branch-per-change policy.

Answer 4

Don't check-in/commit any changes that break a build.

Answer 5

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 6

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

Answer 7

No empty commit messages.

Answer 8

My favorite policy is "No subversion commits that do not reference tickets + Auto Trac comments for each commit": http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook