Jump to first page (C) 1998, Arun Lakhotia 1 Software Configuration Management: Version Control Arun Lakhotia University of Southwestern Louisiana Po Box Lafayette, LA 70504, USA

Jump to first page (C) 1998, Arun Lakhotia 2 Software Configuration Management n Practice of handling changes systematically n Three components u Build control u Version control u Change control

Jump to first page (C) 1998, Arun Lakhotia 3 Traditional Version Control n Common methods of maintaining versons u Copy versions into separate directories F backup F old F old/old F backup.Feb u Copy versions onto separate disks/diskettes and label the disk

Jump to first page (C) 1998, Arun Lakhotia 4 Problems with traditional approach n Inefficient use of storage n Inefficient for storage and retrieval n Inefficient for comparing changes across versions

Jump to first page (C) 1998, Arun Lakhotia 5 Common approaches for working in teams n Each person maintains a copy of the system n Every one works on the same copy of the system n A combination of the two

Jump to first page (C) 1998, Arun Lakhotia 6 Conflicts when working in teams n Multiple programmers may simultaneously modify u different copies of the same files u same file u inconsistent versions of the files

Jump to first page (C) 1998, Arun Lakhotia 7 Version Control Requirements n Provide methods to save the state of a “configuration” at various snapshots in time n Provide methods to revert configuration to an earlier state

Jump to first page (C) 1998, Arun Lakhotia 8 Version Control Capabilities n Version control procedure or tool should provide capabilities to: u identify (name) u time/date stamp u store and retrieve u compare multiple versions of u individual components, or u complete configuration, or u some combination thereof

Jump to first page (C) 1998, Arun Lakhotia 9 Version control tools n Individual file level control u SCCS u RCS n Directory level control u CVS u Razor

Jump to first page (C) 1998, Arun Lakhotia 10 Configuration Repository n A version control tool is essentially a database manager n The database of versions of one or more programs is called a Repository n Process of depositing an item in the repository is called checkin n Process of retrieving an item from the repository is called checkout

Jump to first page (C) 1998, Arun Lakhotia 11 Configuration identification n Configuration item u Primitive components whose versions need be controlled n Baseline u State of all configuration items at some particular time u Baselines are typically defined at completion of certain phases F Functional baseline F Design baseline F Product baseline n All changes made after a baseline has been defined must be controlled (I.e., approved, recorded, etc.)

Jump to first page (C) 1998, Arun Lakhotia 12 Identifying versions: Numbering n Convention for naming versions. n Numbering convention: u Associate two numbers RR.VV F RR is major release F VV is version F Such as 1.0, 1.1, 1.2, 2.0, n Each configuration item has its own version number n Different configuration item within a configuration may have different version number

Jump to first page (C) 1998, Arun Lakhotia 13 Identifying versions: Symbolic n A symbolic name may be assigned to a version number u 2.2 = design-baseline u 3.0 = fully-tested n The “current state” of all configuration items may be given the same symbolic name n Symbolic names may be used to identify the state of the whole system at a given time

Jump to first page (C) 1998, Arun Lakhotia 14 Access control n VC tools control the access of configuration items to prevent conflicts when working in team n Common Access Control mechanisms u Lock at check-out u Complain at check-in

Jump to first page (C) 1998, Arun Lakhotia 15 Lock at checkout n At any time there can be only one checked out copy of an item n Arbitrary number of copies may be taken to peek n A copy may be checked in only if it has been checked out earlier n When an item is added to a repository it is unlocked

Jump to first page (C) 1998, Arun Lakhotia 16 Lock at checkout: State diagram Not in repository lockedunlocked Add to repository Checkout Checkin Peek

Jump to first page (C) 1998, Arun Lakhotia 17 Lock at checkout: Example F1.c F1.h F2.c Baseline: Rel-1 Programmer A Programmer B Checkout: F1.c, F1.h Checkout: F2.c Peek: F2.cPeek: F1.c, F1.h Time: T0 Time: T1 Checkin: F1.c Checkin: F2.c Time: T2 Checkout: F2.c Sorry! Not allowed Time: T3 Time: T4 System inconsistent

Jump to first page (C) 1998, Arun Lakhotia 18 Complain at checkin n There are NO locks n Anyone may retrieve and modify an item n The first one to checkin a modification is allowed n Subsequent checkins are disallowed. To do so the modifications must be merged with the most recent checkout version

Jump to first page (C) 1998, Arun Lakhotia 19 Lock at checkout: Example F1.c F1.h F2.c Baseline: Rel-1 Programmer A Programmer B Checkout ALL Time: T0 Time: T1 Modify: F1.cModify: F2.c Time: T2 Update F1.c Time: T3 Time: T4 Complain! F1.c changed Checkin ALL

Jump to first page (C) 1998, Arun Lakhotia 20 Lock at checkout: Analysis n Benefits u Ensures that there are no simultaneous modifications to the same item. n Drawback u Hampers parallel development u Potential for deadlock: two people waiting on each other to release a locked item

Jump to first page (C) 1998, Arun Lakhotia 21 Complain at checkin: Analysis n Benefits u Supports parallel development u Enables directory level operations n Drawbacks u Requires sophisticated tools for merging changes u Prolonged delays in checkin may make people out of sync

Jump to first page (C) 1998, Arun Lakhotia 22 Summary: Version Control n VC encompasses the tasks involved in managing multiple versions of a (multi- component) system being developed by multiple programmers n There are several tools available that can automate various VC tasks n The VC tools place the source code in a “repository” and provide mechanisms to add, checkin, and checkout items from the repository