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?

A typical numbering scheme Production versions are named 77.88v9 – 77 is “major version number”, also known as “release number”, e.g., Windows 7 – 88 is “minor version number”; minor versions are updates to the release, made occasionally – v9 is “patch level”. Patches are small changes made quickly to solve an urgent problem (e.g., a security hole). or “v” might be “a” for alpha release, “b” for beta release while preparing a new minor or major version This is an example. There are many variations in numbering schemes.

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