Introduction to CVS

1
Introduction to CVS
cutpaste from a talk by Warren Jones, Fluke
Co., Eugene Kramer, Remedy Co.
2
CVS Features

• Concurrent access by multiple developers
• Multiple configurations in a single repository
• Grouping sources into modules
• Symbolic source tagging
• Diffs between versions
• Configurable logging support
• Binary files support
• Repository event triggersIt really isnt
  difficult, but it can be a little awkward.

3
CVS is not

• CVS is not a build system
• CVS is not a substitute for project management
• CVS is not a substitute for communication
• CVS is not an automated testing program
• CVS does not enforce a process model

4
Client-server architecture

• separate server (UNIX or NT)
• no shared filesystems
• a server process per connection

Sandbox
Central repository
Sandbox
Sandbox
5
CVS Repository
cvs.vl-e.nl/global/ices/vlab/cvs
CVSROOT
shr project1 vlam project3
devkits
README doc etc source tools
presentations bin

papers
vlport nl
expect.sh globus.sh

• Resides on a server
• No working files inside the repository

6
CVS Usage Model

• Checkout
• Makes private copy in working directory sandbox
• Can check out anywhere
• Check out multiple copies, multiple versions
• Checkin/Commit
• Commit changes to the repository when finished
• Sandbox must be up to date with repository
• Update
• Brings sandbox up to date with repository

7
Concurrent checkout
Checkout does not lock the files in repository
Master Repository foo.c
checkout latest
checkout branch rel_1_fix
checkout V1.1
checkout V1.2
checkout latest
Karen
Patrick
Brigid
Michael
Chris
checkin
checkin
checkin
X
X
V1.8 or 1.9
V1.2.2.2
checkin prohibited
V1.8 or 1.9
8
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).
• 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.

9
Ideal development with CVS
Developer A
checkout
update
checkin
development
repository
Developer B
10
Real development with CVS
Developer A
repository
Developer B
11
When to commit

• Commit to backup your sources.
• Commit to mark a working state that you might
  want to return to later.
• Commit related files in a single operation.Use a
  common log message for all the files.
• Commit to be able to access the files from
  elsewhere.

12
Working on branches
13
Branch if you need ...

• to create sustaining (patch) releases
• to have multiple development lines from a single
  repository
• to do experimental development to merge later or
  forget about it
• to keep temporary state of development without
  affecting builds

14
Common CVS commands

• cvs cvs-opt command cmd-opt files
• cvs checkout Check out source for editing.
• cvs add Add new file/directory to
  repository.
• cvs remove Remove an entry from the
  repository.
• cvs status Show status of checked out
  files.
• cvs log Show revision history for files.
• cvs diff Compare working files to version
  in
• repository or
  versions inside the repository.
• cvs update Bring working files into sync
  with repository.
• cvs commit Check files into the repository
• cvs tag Label the sources.

15
CVS resources on the web

• Graphical frontends
• Windows WinCVShttp//www.wincvs.org/
• Linux Cervisiahttp//www.cervisia.sourceforge.ne
  t/
• Free ebook
• CVS in open source software developmenthttp//c
  vsbook.red-bean.com/