version control
DESCRIPTION
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 ... - PowerPoint PPT PresentationTRANSCRIPT
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