Agile Version Control Mechanism

I came across a nice paper explaining best practices in using version control (Subversion) in multiple agile team projects. The lack of concept, clarity and existence of understandable rules often leads to confusion in teams I work in.

Branching
Regular merging down from the stable mainline (catch-up) and merge and copy up (publish) of stable features from develoment branches.

Here are some of the rules I found useful:

  • Each branch (even the trunk) has an owner and a policy.
  • Agree on a common definition of Done = releasable (means Unit tested and integration tested).
  • Trunk is the Done branch, it should contain releasable code at any time.
  • Branch policy = Unit tested code, new releasable features or bugfixes.
  • Don’t combine different release cycles on a single branch.
  • Create additional branches as seldom as possible. Only create a new branch when you have something you want to check in, and there is no existing branch that you can use without violating its branch policy.
  • Whoever touches the trunk is responsible for ensuring that the whole trunk stays releasable – including all previous functionality.
  • Synchronize your code with the work branch continuously (daily).
  • Code conflicts and integration problems should be discovered as soon as possible.
  • Resolve conflicts on the branch that is least stable. Whoever checks in first wins.
  • Merge from your work branch to the trunk on a regular basis, for example whenever a story is done. Don’t wait until the end of the sprint.
  • Merge down, copy up.

Revision flow
Flow of changes around the mainline of your project.

Taken from the paper “Agile version control with multiple teams” of Henrik Kniber which you should read if you are not already an expert in branching and tagging across teams.