Introductory Concurrent Version System (CVS) - PowerPoint PPT Presentation

View by Category
About This Presentation

Introductory Concurrent Version System (CVS)


Introductory Concurrent Version System (CVS) UCR Technical Seminar 10/23/03 Dan Berger – PowerPoint PPT presentation

Number of Views:77
Avg rating:3.0/5.0
Slides: 37
Provided by: ucr90
Learn more at:


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Introductory Concurrent Version System (CVS)

Introductory Concurrent Version System (CVS)
  • UCR Technical Seminar
  • 10/23/03
  • Dan Berger

  • Introduction
  • What is configuration management?
  • Key concepts.
  • CVS Workflow
  • Copy-Modify-Merge
  • Getting Started with CVS
  • Creating a repository
  • Importing assets
  • Checking in Checking Out
  • Using CVS
  • Managing Change

Introduction What is CM?
  • Record Keeping
  • What assets (source, binary) went into producing
    some product?
  • What did this asset look like at some point in
    the past?
  • Collaboration
  • Who's working on which assets?
  • Who worked on this asset last?
  • Who made a specific change to this asset (and

Introduction Key Concepts
  • Repository The master copy of the assets.
  • Contains all revision history for all assets.
  • Working Directory (aka sandbox) a developers
    private copy of the assets.
  • Contains a copy of a particular version of assets.

CVS Workflow
  • CVS allows multiple people to be working on the
    same set of assets at the same time.
  • Copy-Modify-Merge means you take a copy of the
    assets, modify your local copy, and merge your
    changes back in to the master repository.

CVS Workflow (cont.)
  • cvs checkout ltprojectgt
  • edit to your hearts content
  • cvs update
  • resolve conflicts
  • cvs commit

Getting Started w/ CVS
  • Creating a Repository (one time only)
  • Importing Assets
  • Checking out a working copy
  • Viewing changes
  • Committing changes
  • Working with previous versions

Creating a Repository
  • export CVSROOT/CVSRoot
  • cvs init
  • ls l CVSROOT
  • drwx------ CVSROOT/
  • There are some magic files in CVSROOT/CVSROOT
    ignore them for now.

Importing Assets
  • importing places a copy of an existing directory
    tree (rooted at pwd) into the repository
  • cvs import mod-path vendor release
  • mod-path is the directory under CVSROOT to
    import the files into
  • vendor and release are more complicated but (for
    our purposes) less important.
  • I suggest vendorwhoami, releaseinitial.

Importing Assets Example
  • cvs import cvs-seminar/hello-world\ whoami
    initial \
  • m initial import
  • N cvs-seminar/hello-world/hello.C
  • N cvs-seminar/hello-world/Makefile
  • No conflicts created by this import

Importing Assets (Cont.)
  • Importing assets doesnt touch the files in the
    current directory.
  • That also means changes to the files in the
    working directory arent tracked.
  • We need to get a copy from the repository first

Getting a Working Copy
  • cvs checkout \
  • cvs-seminar/hello-world
  • cvs checkout Updating cvs-seminar/hello-world
  • U cvs-seminar/hello-world/Makefile
  • U cvs-seminar/hello-world/hello.C
  • ls l cvs-seminar/
  • CVS/
  • ls l cvs-seminar/hello-world
  • CVS/
  • hello.C
  • Makefile

Viewing Changes
  • Imagine we changed the files fixing the typo in
    hello.C and adding a default target to the
  • Before we commit these changes, wed like to see
    what we actually changed
  • cvs can show us which files have changed, and/or
    the specific changes to the files.

cvs -n update
  • cvs n update
  • cvs update Updating .
  • M Makefile
  • M hello.C
  • ? hello
  • the leading M indicates the file has been
    Modified. The ? means the file isnt being
    managed by CVS.

cvs diff
  • cvs diff hello.C
  • Index hello.C
  • RCS file
  • retrieving version
  • diff r hello.C
  • 11c11
  • lt cout ltlt Helllo, world! ltlt endl
  • ---
  • gt cout ltlt Hello, world! ltlt endl

cvs status
  • cvs status will tell you the status of a file in
    your working copy.
  • cvs status hello.C
  • File hello.C Status Up-to-date
  • Working revision x.x
  • Repository revision x.x

Adding Files
  • CVS will essentially ignore new files, until
    you tell it theyre important and should be
  • cvs add README
  • cvs add scheduling file README for addition
  • cvs add use cvs commit to add this file

Deleting Files
  • first, remove the file from your working copy
    (with rm), then
  • cvs delete file
  • cvs remove scheduling FILE for removal
  • cvs remove use cvs commit to remove \
  • this file permanently
  • cvs commit
  • Removing FILE
  • /FILE,v lt-- FILE
  • new revision delete previous revision 1.1
  • done

Removing Files (cont.)
  • CVS doesnt actually remove the file, it places
    it into the Attic.
  • You can still retrieve any version of the
    deleted file
  • cvs up r X.Y FILE
  • U FILE

  • One place where CVS makes life difficult.
    Renaming files is non-trivial.
  • Two methods
  • one that preserves change history, but requires
    file system access to the repository,
  • and one that breaks change history but can be
    done completely through the client.

Renaming The Easy Way
  • cp old-name new-name
  • rm old-name
  • cvs delete old-name
  • cvs add new-name
  • cvs commit
  • You can explain the rename in the log message,
    and point viewers to the old-name for complete
    revision history.

Committing Changes
  • Once were happy with our changes, we need to
    commit them to the repository.
  • We can commit all our changes, or changes to an
    individual file (often dangerous).

Checking In Example
  • cvs commit
  • cvs commit Examining .
  • Checking in Makefile
  • /Makefile,v lt-- Makefile
  • new revision 1.2 previous revision 1.1
  • RCS file /README,v
  • done
  • Checking in README
  • /README,v lt-- README
  • initial revision 1.1
  • done
  • Checking in hello.C
  • /hello.C,v lt-- hello.C
  • new revision 1.2 previous revision 1.1
  • done

Working with Versions
  • the r tag can be provided to CVS commands, and
    it will cause them to affect a specific version
    of the named asset.
  • For example
  • cvs diff r 1.1 Makefile
  • You can also check out previous versions of files
    (cvs co r x.x filename), and even commit to
    (branch from) previous versions of files.

Diff and Patch
  • Not strictly CVS related, but terribly valuable
  • diff generates the differences between two (sets
    of) files.
  • patch can apply that set of differences to
    another file

Diff Example
  • Say I have two copies of my project
  • unmodified-copy and modified-copy
  • diff Naurw unmodified-copy \ modified-copy
  • CVS will do this also, without having two
    versions checked out
  • cvs diff auw r other-version

Patch Example
  • Once I have a unified diff (the u to diff), I
    can apply the changes specified in the diff to
    another file
  • patch lt diff-file
  • This also works with trees of files.
  • Read the man page to patch for more options.

CVS Version Numbers
  • Imported files have an initial version of
    theres a reason, but for now just ignore it.
  • Normal version numbers are w.x cvs
    automatically increments x each time you commit
    changes to the file. It never automatically
    increments w.
  • If you branch a file, its version number becomes
    w.x.y.z. Were not going to talk about branches
    in this talk. (Advanced CVS, anyone?)

CVS Magic Strings
  • Some strings have special meaning to CVS, and if
    they appear in your files, CVS will evaluate
    them during checkout.
  • Id is the most common/useful, it gets
    evaluated to a string of the form
  • Id Makefile,v 2003/10/20 \ 230820
    dberger Exp

CVS and Binary Files
  • CVS assumes that files are text unless told
    otherwise. This can cause issues if a binary
    file (like a jpg, PDF, etc.) contains one of the
    magic strings mentioned above.
  • This can be handled two ways file-by-file, or by
    file extension
  • cvsadmin kb file
  • or adding the extension to cvswrappers (more

  • CVSROOT/ contains control files many of which
    are only interesting if youre using CVS in a
  • CVSROOT is just another module so you can check
    it out/diff it/commit to it.
  • Remember cvswrappers? It lives here it
    allows hooks to run when files go in or out of
    CVS. Theres a sample linked from the tech
    seminar page.

Accessing CVS Remotely
  • Three methods, pserver, rsh, ext.
  • pserver is a cvs-specific network protocol, its
    not encrypted and has to be setup by the remote
    admin so were going to ignore it.
  • rsh is just too horrible for words, which leaves
  • export CVS_RSHssh
  • export CVSROOT \ extuser_at_host/path/to/cvs
  • note that cvsroot is the directory containing

Remote CVS (cont.)
  • Note that if your CVS repository is NFS exported
    and always available directly (I.e. its in your
    home directory), you dont need to use the ext
    method to reach it.
  • export CVSROOT/home//CVSRoot

What We Didnt Cover
  • cvs watchers and editors
  • anonymous cvs
  • CVS and IDEs (emacs/eclipse, etc)
  • Permissions
  • Tagging
  • Branching
  • Merging
  • Detecting and Resolving Conflicts

  • ltskepticgt a better CVS lt/skepticgt
  • You cant set it up for yourself (its repository
    cant live on an NFS share, like your home
  • The command line interface is very similar

Where to Find More
  • CVS Home Page http//
  • CVS Online Book http//
  • CVS GUIs http//
  • TortoiseCVS (Windows Explorer Extension)
  • Subversion Home Page http//
  • Subversion Online Book (draft)