190 likes | 362 Vues
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 ...
E N D
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