1. 1 CMPT 275 Software Engineering Revision Control

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

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

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

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

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

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

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

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

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

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

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

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

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