Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 CMPT 275 Software Engineering Revision Control.

Similar presentations

Presentation on theme: "1 CMPT 275 Software Engineering Revision Control."— Presentation transcript:

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  facilities/csil/unix/svn-tutorial.html facilities/csil/unix/svn-tutorial.html  facilities/csil/how-to-use-subversion.html Janice Regan, 2008 14

Download ppt "1 CMPT 275 Software Engineering Revision Control."

Similar presentations

Ads by Google