1 CMPT 275 Software Engineering Revision Control
Janice Regan, 2008 2 Software Configuration Items Items that comprise all information produced as part of the software development process Documents Source code Test cases Data Development environment are collectively called software configuration items
Janice Regan, 2008 3 Some definitions Version: instance of a software system that differs from other instances Release: a version distributed to a customer Revision: a revised software configuration item (SCI) Build: compiled version of a software system at a particular time during development. May be a version, a release, or an intermediate system
Janice Regan, 2008 4 Software Configuration Management Change Control Keep track of all changes to a particular release of the project Release Management Plan what features to include in which release Plan when releases will be made
Janice Regan, 2008 5 Software Configuration Management Source Code and Document Control Manage changes to project documents and code Development Environment Configuration Provide a consistent development environment for all developers on a project
Janice Regan, 2008 6 Imagine … Scene 1 You are working on a large project, there are several programmers working on the same build of the software. Each of the developers are using the same previous build as a basis for their development. Each developer is revising and implementing a different set of methods.
Janice Regan, 2008 7 Imagine … How do you document and communicate your changes to the rest of the team? How do you make sure you have your teammates additions to the build? How do you assure that an up to integrated version of the developers efforts is maintained?
Janice Regan, 2008 8 Source Code Control How to control our source code? Tools: Software version control such as RCS, CVS, SourceSafe, SubVersion (SVN) Do you know any others? These tools allow: (Us to build project DB (or library)) Either file lock or concurrent editing File versioning Inclusion of comments for a version
Janice Regan, 2008 9 Why use Source Code Control? You may: Work with other software developers Work on projects containing thousand of files You will: Delete your code when you should not have Delete somebody else’s code when you should not have Make change that breaks something and not know how you did it You must be able to recover from these problems efficiently
Janice Regan, 2008 10 How does Source Control Work? The code for the project will be stored in a central location, often administered by a librarian When a developer wishes to make a change, they must check out a copy of the current version of the project They make their changes and additions to that copy of the project, then have those changes and additions tested. When their changes/additions are stable then They put their changes into the central library copy of the project (or ask the librarian to do so) Before putting their changes back they may need to integrate changes made to the central library since they checked out their copy, and retest their additions/changes
Janice Regan, 2008 11 Types of source control systems Some source control systems use locks When a developer has checked out a copy of a package then that package is blocked No other developer can check out a copy of the same package until the first developer checks their tested changes back in The lock may be on checking a copy of the entire system, even if the developer wishes to modify one package within the system The lock may be on a per package basis, allowing use of the present system but changes only to the package checked out.
Janice Regan, 2008 12 Types of source control systems Some systems are more sophisticated and can merge multiple simultaneous changes This permits multiple programmers to modify or extend different packages or different parts of the same package at the same time If multiple programmers modify the same line of code, manual merging may still be necessary The increased flexibility of non blocking systems is needed when multiple programmers need to work on different parts (packages, methods within a package, bugs or added features within a method)
Janice Regan, 2008 13 Steps: using a non-blocking system A particular build of the software system will be used as the reference system. Each developer will check out a version of this reference system and make their desired changes or additions. When developer A's tested changes are ready to be committed (integrated into the reference system) then developer A must update his build to be consistent with the reference version, then retest the resulting build A build is updated by including all changes committed by other developers since developer A checked out his version Once developer A has updated his version to be consistent with the present reference version and retested, his changes can be committed into the reference version
Information about SVN http://www.cs.sfu.ca/about/school- facilities/csil/unix/svn-tutorial.html http://www.cs.sfu.ca/about/school- facilities/csil/unix/svn-tutorial.html http://www.cs.sfu.ca/about/school- facilities/csil/how-to-use-subversion.html Janice Regan, 2008 14