1 / 13

Version Control

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 ...

zanthe
Download Presentation

Version Control

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Version Control How and why to control changes in a software artifact

  2. 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

  3. 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”

  4. 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.

  5. 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

  6. 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, ...

  7. 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.

  8. 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?

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

  10. 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

  11. 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

More Related