Version Control and CVS

1
Version Control and CVS

• What is revision control for
• Comparing CVS to other revision control systems
• What CVS does well
• What CVS does badly
• Using CVS for revision control on your computer
• Working with Open Source projects that use CVS

2
What a VCS is good for

• History
• Keeps track of changes and allows you to
  backtrack to any previous version, as well as
  review the changes that were made.
• Keeps a history (who, what, when).
• Forms a knowledge base over time.
• Distributed Development
• Allows different people to work on one project
  and provides a means to manage these separate
  development efforts.
• Allows different approaches to a problem to be
  tried separately, and later merged back in.

3
Comparison of some VCS softwares
Rumor has it that Perforce will often give away
licenses to open-source projects. Bitkeeper
has an elaborate open-source policy, whereby you
can use Bitkeeper for an open-source project for
free, but they have total access to what you
do. Bitkeeper's website has a comprehensive
(although obviously biased) comparison of all
their competition.
4
What CVS does well

• Allowing separate developers to work
  independently and then integrate their changes.
• CVS is very good at tracking the changes made to
  text files, and can help you see exactly what has
  changed between one version and the next (through
  diffs).

5
What CVS does poorly

• CVS doesn't do a good job of showing you the
  changes that have been made to non-text files
  (such as images).
• It's difficult to rename or move files or
  directories.
• CVS is not a substitute for good project
  management, it is just a tool to make it easier
  to manage.
• CVS is not a substitute for good backups.
• Branching can be somewhat complicated.

6
Key Concepts of CVS

• Repository Directory tree that contains files
  with version history
• Working Copy A local copy of a particular
  version of the repository
• It's important to understand diff(1) and patch(1)
  in order to use CVS effectively.

7
Creating a Local Repository

• cvs -d /your/respository init
• Create a backup of the files you want to import
  into the repository.
• Import the files into the repository usingcvs
  -d /your/repository import -m message
  \projname vendortag releasetag
• Delete the previous files (you made a backup,
  right?)
• Checkout a new working copy withcvs -d
  /your/repository co projname
• Repeat 2-5 for any additional projects

8
Some things to know

• Set the CVSROOT variable to save typing
• Set VISUAL and/or EDITOR to something you like
• 'cvs diff index.html' to see what's changed
• 'cvs update' to get all the latest versions (and
  see an overview of changes)
• 'cvs add newfile.html' to add a new file (doesn't
  happen until you commit)
• 'cvs commit changedfile.html' to commit the
  changes to changedfile.html
• Id will be expanded by CVS to (for
  example)Id phppdflib.class.php,v 2.7
  2003/11/27 035816 wmoran Exp

9
Reverting changes

• If you make a change and change you mind (in this
  example we decide that the 1.4 version of
  index.html was a bad idea)
• cvs update -j 1.4 -j 1.3 index.html
• cvs ci -m backed out 1.4 change index.html
• (Note that the working copy of index.html must be
  up to date with version 1.4 before doing this
  or the results are unpredictable)

10
Tagging releases

• Tags capture a moment in time, bringing different
  versions of all files together under a friendly
  name.
• To tag the current versions in your working copy
• cvs tag tagname

11
Introduction to Branching

• Two times branching occurs When you want to try
  two different approaches and see which one works
  out and when you have two versions to track
  seperately (such as a bugfix track, and a
  development track)
• To branch
• cvs tag -b ver1bugfixes
• You can then checkout a new working copy of the
  branch to make updates to.

12
Repository management for dummies

• Repositories are just files and directories
• The ,v files contain the entire version history
  for a particular file
• To move or rename a file or directory, you can
  just use mv, etc
• Deleting a file should be done with the cvs
  command, so the file history is maintained
• Setting permissions is done by setting UNIX file
  permissions on the repository files/directories

13
Working with CVS online

• Use pserver for the CVSROOT (or
  -d)pserverusername_at_cvs.host.com/dir
• username is usually anonymous. This will allow
  you to checkout different versions from CVS, but
  you'll not have write access.

14
cvsup

• cvsup is a quick way to track a project (i.e.
  maintain up to date versions of many files in a
  repository)
• Uses compression and diffs to make best use of
  even slow network connections. Very efficient
  way to checkout a large project.

15
Using cvsup to track FreeBSD 4.9

• Create a supfiledefault hostcvsup.freebsd.org
  default base/usrdefault prefix/usrdefault
  releasecvs tagRELENG_4_9default delete
  use-rel-suffixsrc-all
• Start cvsupcvsup supfilecvsup -g supfile (for
  non-X)