2. 1 IST 410/420 Software Version Control

3. 2 DevelopmentIntegration Test System Test User Acceptance Testing ProductionArchive DEVELOPMENTUSERS - Developers personal environment – you own the code - Unit Testing - as many environments as developers - source code management required - Owned by developers - Own the data too - Users own the data and environment - Usually a copy of production (currently in use) - Users are using it day to day - Users own the data and the environment Planning Full System - Analysis & Design - Inception/Elaboration Source code control Software Version Control System Test Instructor Acceptance Testing

4. 3 What is CVS? Concurrent Versions System Version Control System Multi-developer environment

5. 4 What is CVS 2? CVS is a version control system. Using it, you can record the history of your source files. CVS also helps you if you are part of a group of people working on the same project.

6. 5 CVS Repository Developer 1 Developer 2 Developer 3 Developer 4

7. 6 checkoutupdatecheckindevelopment Ideal development with CVS repository Developer A Developer B

8. 7 Definitions-Repository The Repository is a directory tree containing the CVS administrative files and all the Revision Control System (RCS) files that constitute "imported" or "committed" work. Kept in a shared area, separate from the working areas of all developers.

9. 8 Definitions-RCS An RCS file is a text file containing the source text and the revision history for all committed revisions of a source file. Stored separately from the working files, in a directory hierarchy, called the Repository. RCS file names normally end in ",v".

10. 9 Definitions-Working file A working file is a disk file containing a checked-out copy of a source file that earlier had been placed under CVS. If the working file has been edited, the changes since the last committed revision are invisible to other users of CVS. A working directory is the place where you work and the place from which you "commit" files.

11. 10 Definitions-Checkout Checking out" is the act of using the "checkout" command to copy a particular revision from a set of RCS files into your working area. You normally execute "checkout" only once per working directory (or tree of working directories), maintaining them thereafter with the "update" command.

12. 11 Definitions-Revision A "revision" is a version of a file that was "committed" ("checked in", in RCS terms) some time in the past. Each version of a file has a unique revision number. Every file in a CVS repository can contain many versions, which are given revision numbers in form x.y[.x.y[...]]. ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !

13. 12 Definition-Tag-symbolic revision A release of a system will have many different revision numbers To let you find all the files in a release, use tags.

14. 13 Development 2.2.3 Integration Test 2.2.2 System Test 2.2.1 User Acceptance Testing 1.2 Production 1.1 Archive 1.0 DEVELOPMENTUSERS - Developers personal environment – you own the code - Unit Testing - as many environments as developers - source code management required - Owned by developers - Own the data too - Users own the data and environment - Usually a copy of production (currently in use) - Users are using it day to day - Users own the data and the environment Planning 3.0 Full System - Analysis & Design - Inception/Elaboration Source code control Software Version Control

15. 14 Definition-Branch Version number can contain more than two numbers to mark branches. Reasons to branch: fix bugs in product while working on next version work on subproject that will take a week to finish

16. 15 Working on branches 1.11.21.3 release_1 cvs tag release_1 cvs up -r rel_1_fix 1.4 release_2 cvs tag release_2 1.2.2.11.2.2.2 patch rel_1_fix cvs tag -b rel_1_fix

17. 16 checkin X Real development with CVS repository Developer A Developer B updateconflict resolution checkin conflict

18. 17 CVS and the Development Cycle 1. Check out source files in working directory. 2. Edit source files. 3. Unit test your code. 4. Update working files to merge in changes from other developers (if necessary).

19. 18 CVS and the Development Cycle 5. Test again if the sources were merged on step 4. 6. Commit changes. 7. Repeat from step 2 until you have a new release. 8. Tag the release. 9. Submit the module name and release tag for integration build.

20. 19 Useful CVS commands cvs [cvs-options] command [cmd- options] [files] cvs checkoutCheck out source for editing. cvs commitcheck files into the repository (check in) cvs addAdd new file/directory to repository. cvs removeRemove an entry from the repository. cvs updateBring working files into sync with repository.

21. 20 Useful CVS Commands(con.) cvs diffCompare working files to version in repository or versions inside the repository. cvs logShow revision history for files. cvs statusShow status of checked out files. cvs tagLabel the sources.