Version Control

How and why to control changes in a software artifact

Software changes ...

• While we build it ...– Multiple people are building and improving the

software at the same time• Even after we deliver it ... – Every successful software system continues to be

improved and adapted over time

• Uncontrolled parallel change can be chaos

Two sides to change control

• Policy side: – How do we choose, plan, and manage change

• Mechanism side: – How do we keep track of changes and avoid

danger– inconsistent changes, lost changes, inability to recreate a

previously working version

– Mechanism side is called “version control”

Change Control Policy: Small Development Projects

• Access policy• Do developers “own” their part of the code? Can every

developer change any part of the code?

• Change planning and communication• Everyone should know what is currently stable and what is

currently undergoing change (by whom)

• Coordinating change• A typical plan might be to work independently Monday-

Wednesday, then integrate Thursday and Friday.• Policies vary (e.g., integration could be daily or continuous);

the worst policy is not having a policy.

Change Control Policy: Larger Projects

• Typically multiple current versions– e.g.: Production, Beta, Development versions

• Much more complex– for example: Should a bug fix in the production

version be applied also to the development version? Who decides?

• A change control board may be in charge of approving changes in a large project

Technical Side: Version Control

• Each developer works on a personal copy of the system

• Version control system (VCS) manages changes• Check out a current copy; make changes; get changes

from others; check for conflicts; apply changes to baseline version

• Many examples: RCS, CVS, Subversion, Mercurial, GIT, ...

Using a Version Control System*

• Someone sets up a shared repository• Each developer– Checks out a working copy to their own workspace– Makes changes to their personal copy– Updates with changes from others– Tests for consistency– Commits changes to shared repository

Important! VCS can only check for

overlapping changes, not consistency

*This is for a VCS with a shared repository (like SVN). Some VCS (e.g., GIT) have no single repository, but accomplish the same thing by combining changes from each developer’s working copy.

Policy + VCS

• You need policies in how VCS is used• Examples: – Should code be reviewed before it is committed to

the shared repository? – How often should changes be committed? Is

there a regular schedule, or a plan? – When do we save a copy of the most recent code?– How do we identify versions?

Prolonged fork: A version control pathology of process. Technology can’t fix this.

Version control anti-patterns

• Prolonged fork (delayed check-in)• Member or sub-team holds changes too long;

remainder of team cannot test against new or changed functionality.

• Broken check-in• Member or sub-team checks in without integration

test, “breaking the build” for others

• Lost update• Member of sub-team “resolves” conflicts by discarding

the changes made by others

Summary: Change Management

• Policy + Tools (VCS): Both are needed• Policy for managing change. – May be simple for small projects. May be quite

complex for large projects.• Version control system for coordinating– Allows developers to work on personal copies,

then check consistency before applying changes to the shared system