1 / 14

CMPT 275 Software Engineering

CMPT 275 Software Engineering. Revision Control. Software Configuration Items. Items that comprise all information produced as part of the software development process Documents Source code Test cases Data Development environment

sadie
Download Presentation

CMPT 275 Software Engineering

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. CMPT 275Software Engineering Revision Control

  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. Some definitions • Version: instance of a software systemthat 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. 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. 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. Imagine … • Scene 1You 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. 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. 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. 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. 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. 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. 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. 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/how-to-use-subversion.html

More Related