Configuration Management

1
Configuration Management

• a.k.a. source code control,
• version control, CM

2
Why CM?

• Multiple developers
• Multiple phases (alpha, beta, released)
• Multiple released versions of software
• Multiple platforms for software

3
Simple CM

• A directory for each version
• Make new version by copying old
• Two developers never edit same file at same time

4
More complex CM

• All versions stored in a database
• Each file is stored in database separately
• fetch version 3.4 of all files and put them into
  johnson/project3.4
• Edit files, compile, test, etc.
• store johnson/project3.4 as next version

5
Problems

• What if two developers want to change the same
  file?
• 1) Dont let them. You must lock a file
  before you can edit it. Only one person can lock
  a file.
• 2) Let them. You must resolve differences when
  you check the files back into the database.

6
Locking

• Checkout for reading - readonly file.
• Checkout for writing - writable, but must lock
  file.
• Checkin writable file - create new version,
  unlock file.

7
Problem

• How can you tell whether a set of files are
  compatible?
• 1) Label them. Each file has something like
  version that is put in a comment.
• 2) Group them. The CM system keeps track of all
  related files, and checks them in and out as a
  group.

8
Building software

• make knows all the files it takes to build a
  program
• Why not have CM system know all the files?
• Can check them all out at once
• Can check them in

9
Building software

• Good CM system should be able to retrieve any
  version.
• 1) Store binaries of old versions.
• 2) Know how to rebuild binaries of old versions.
• Must keep old versions of libraries.
• Must keep old versions of compiler, etc.

10
How to use a CM system

• To fix bug
• Check-out most recent version
• Change, compile, test, etc.
• Check-in next version.
• If someone checked-in before you, get the
  changes, manually merge them, compile, test, etc.
  Try again.

11
How to use a CM system

• If you dont check out code for a long time then
• When you check-in, youll find lots of conflicts.
  It will take a long time to make your code ready
  to check-in.
• So, make lots of small changes rather than a few
  big ones.

12
CM tools

• Unix - CVS
• Windows - SourceSafe
• See http//www.enteract.com/bradapp/links/scm-lin
  ks.html

13
CVS

• Records history of source files
• Efficiently records every version
• Helps developers work concurrently
• Runs on a server

14
Connecting to server

• Must specify server by setting environment
  variable
• Must have account on the server
• There can be many directories on the server
• setenv CVSROOT pserverjohnson_at_cvsserver.cs.uiuc
  .edu/cvsroot
• cvs login

15
CVS
Developer 4
Repository
Developer 1
Developer 3
Developer 2
16
Things to do with CVS

• Get source code
• Put new version back into repository
• Compare differences between versions
• Create, delete, change permissions, etc

17
Checking out source code

• cvs checkout poker
• cd poker
• ls
• CVS makefile cards.c cards.h poker.c

18
Checking in source code

• emacs poker.c
• cvs commit poker.c
• CVS will ask you for a comment to describe the
  change

19
Conflict

• cvs update driver.c
• RCS file /usr/local/cvsroot/uiuc/poker/poker.c,v
• retrieving revision 1.4
• retrieving revision 1.6
• Merging differences between 1.4 and 1.6 into
  poker.c

20
Conflict (continued)

• rcsmerge warning overlaps during merge
• cvs update conflicts found in poker.c
• C poker.c
• emacs poker.c

21
Conflict (continued_

• ltltltltltltltltltltpoker.c
• old lines
• new lines
• gtgtgtgtgtgtgtgtgtgt 1.6

22
Merging

• CVS does a good job at merging
• Reports conflicts it cannot merge
• Merges usually work unless there is a conflict
• But not always!

23
Summary

• cvs co get source code from repository
• cvs update d get latest version
• cvs ci put source code in repository
• cvs ci will complain if it is not the latest
• cvs update will merge and complain if it cant
  merge

24
Basic activity of using CVS

• Check out/update code.
• Modify and test it.
• Check it back in. If there are conflicts, fix
  them and check back in again.
• The longer your code is checked out, the more
  conflicts there will be.

25
Cleaning up

• cvs release -d poker
• M poker.c
• You have 1 altered files in this repository.
• Are you sure you want to release (and delete)
  module poker' n
• release' aborted by user choice.

26
Coordinating developers

• cvs watch on files - make readonly
• cvs watch off files
• cvs watch add files - notify me if written
• cvs watch remove files
• cvs edit files - let me write, notify others
• cvs unedit files

27
Revisions

• Revision number 2.4 or 1.7.3.3 or 6.3.1.3.1.1
• Normal commit will increment last number
• Creating a branch will add .1.1 to the end
• Different files will have different revision
  numbers

28
Tag

• A release of a system will have many different
  revision numbers
• To let you find all the files in a release, use
  tags.
• cvs tag poker-2-2 .c .h makefile

29
Branch

• Reasons to branch
• fix bugs in product while working on next version
• work on subproject that will take a week to finish

30
Branches

• Create a branch
• cvs tag -b poker2.0-beta
• Create a directory holding a branch
• cvs checkout -r poker2.0-beta poker
• Change your directory to a particular branch
• cvs update -r poker2.0-beta poker

31
Merging branches

• cvs update j poker2.0-beta
• Merges changes between the current version and
  the version tagged poker2.0-beta
• Then do cvs ci to store changes in the
  repository.

32
Branches

• Avoid branches if possible.
• Reasons to branch
• Fixing bugs in customer version
• Experimental version
• Political fights

33
Bad reasons to branch

• Support different hardware platform
• Make subclasses / use conditional compilation /
  make portability library
• Support different customer
• Separate unchanged code from changed code
• Unchanged code goes in a library
• Make subclasses / use conditional compilation for
  changed code

34
For more info on CVS see

• http//www.cvshome.org
• http//cvsbook.red-bean.com/
• http//www.loria.fr/molli/cvs/doc/cvs_toc.html
• www.sourceforge.net