Introductory Concurrent Version System (CVS)

1. Introductory Concurrent Version System (CVS) UCR Technical Seminar 10/23/03 Dan Berger dberger@cs.ucr.edu

2. Adgenda • 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

3. 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 when?)

4. 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.

5. 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.

6. CVS Workflow (cont.) • cvs checkout <project> • edit to your hearts content… • cvs update • resolve conflicts • cvs commit

7. 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

8. 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.

9. Importing Assets • importing places a copy of an existing directory tree (rooted at `pwd`) into the repository • cvs import mod-pathvendorrelease • 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 vendor=`whoami`, release=“initial”.

10. 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

11. Importing Assets (Cont.) • Importing assets doesn’t touch the files in the current directory. • That also means changes to the files in the working directory aren’t tracked. • We need to get a copy from the repository first…

12. 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

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

14. 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 isn’t being managed by CVS.

15. cvs diff % cvs diff hello.C Index: hello.C ========================================= RCS file: … retrieving version 1.1.1.1 diff –r 1.1.1.1 hello.C 11c11 < cout << “Helllo, world!” << endl; --- > cout << “Hello, world!” << endl;

16. 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 …

17. Adding Files • CVS will essentially “ignore” new files, until you tell it they’re important and should be managed. % cvs add README cvs add: scheduling file ‘README’ for addition cvs add: use ‘cvs commit’ to add this file permanently

18. 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 <-- FILE new revision: delete; previous revision: 1.1 done

19. Removing Files (cont.) • CVS doesn’t 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

20. Renaming • 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.

21. 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.

22. Committing Changes • Once we’re 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).

23. Checking In Example % cvs commit cvs commit: Examining . Checking in Makefile; …/Makefile,v <-- Makefile new revision 1.2; previous revision 1.1 RCS file: …/README,v done Checking in README: …/README,v <-- README initial revision 1.1 done Checking in hello.C …/hello.C,v <-- hello.C new revision 1.2; previous revision 1.1 done

24. 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.

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

26. 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

27. 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 < diff-file • This also works with trees of files. • Read the man page to patch for more options.

28. CVS Version Numbers • Imported files have an initial version of 1.1.1.1 – there’s 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, it’s version number becomes w.x.y.z. We’re not going to talk about branches in this talk. (Advanced CVS, anyone?)

29. 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 1.2.1.3 2003/10/20 \ 23:08:20 dberger Exp $

30. 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 later)

31. ${CVSROOT}/CVSROOT • CVSROOT/ contains control files – many of which are only interesting if you’re using CVS in a group. • CVSROOT is just another module – so you can check it out/diff it/commit to it. • DON’T TOUCH THESE FILES DIRECTLY! • Remember “cvswrappers”? It lives here – it allows hooks to run when files go in or out of CVS. There’s a sample linked from the tech seminar page.

32. Accessing CVS Remotely • Three methods, pserver, rsh, ext. • pserver is a cvs-specific network protocol, it’s not encrypted and has to be setup by the remote admin – so we’re going to ignore it. • rsh is just too horrible for words, which leaves ext: % export CVS_RSH=ssh % export CVSROOT= \ :ext:user@host:/path/to/cvsroot • note that cvsroot is the directory containing CVSROOT/

33. Remote CVS (cont.) • Note that if your CVS repository is NFS exported and always available directly (I.e. it’s in your home directory), you don’t need to use the ext method to reach it. % export CVSROOT=/home/…/CVSRoot

34. What We Didn’t Cover • cvs watchers and editors • anonymous cvs • CVS and IDE’s (emacs/eclipse, etc) • Permissions • Tagging • Branching • Merging • Detecting and Resolving Conflicts • …

35. Subversion • <skeptic> a “better” CVS </skeptic> • You can’t set it up for yourself (it’s repository can’t live on an NFS share, like your home directory). • The command line interface is very similar (intentionally).

36. Where to Find More • CVS Home Page: http://www.cvshome.org • CVS Online Book: http://cvsbook.red-bean.com • CVS GUI’s: http://www.wincvs.org • TortoiseCVS (Windows Explorer Extension): http://www.tortoisecvs.org • Subversion Home Page: http://subversion.tigris.org • Subversion Online Book (draft): http://svnbook.red-bean.com