The Basic Change Process

This diagram illustrates the basic change process:

1. Start at a known good revision of the code
2. Branch and make changes
3. Meanwhile, someone else completes a change, and puts it into the main line (hopefully after passing review, QA, etc)
4. You pull and merge
5. You copy back into the main line, again after passing review, QA, etc...

This process should be engrained in every software engineer. Even the grandfather of concurrent revision control systems, CVS, is built up around this model, as long as you consider your checkout to be an effective branch of the code, which it is...

As an aside, I am very pleased to see that Perforce finally, after almost twenty years of procrastination, introduced streams, which implement this exact change process directly, and not as one of many many options in a free-form depot structure.


The trick is to continue following this model as your code base and your team's size grows. Common objections are:

• I don't trust (3), so I don't want to do (4) and risk endangering my code because of (3)'s changes.
• I just know that (3) is completely orthogonal, so I can do (5) without doing (4).
• I don't trust (3), so I'll hold off with (4) until I finally have to do (5).
• Merging other people's code takes up too much of my time, so I'll hold off, especially since the changes seem to be mostly from places I don't care about.

The net effect is that the merges will either be too simple, as they assume orthogonality and that lack of conflict means lack of risk, or that they will become too complex, as people hold off forever.

There are two antidotes to these objections:

• Increase the requirements for performing step (5), in order to ensure that your mainline is always clean and releasable. I have come a long way to finally conclude that the best requirement is not only to have passed review and QA, but to actually have been deployed or released prior to getting copied into your mainline. Your mainline should be a true representation of what is in production, and nothing less than that. Later posts will expand on that theme....
• Keep the size of your source tree small. Split your source tree into components, modules, packages, artifacts or whatever is convenient and develop, build and release them separately. Yes, this increases the tracking burden, but it will keep the basic change model intact, and help implement the first point of making your mainline represent production. Again, later posts will expand on that theme.

The main point is that the slippery slope begins as soon as you attempt to optimize or otherwise deviate from the basic change process. Resist the temptation and use the two antidotes instead.