CVS Workshop I

Arthur Chan

This workshop

CVS overview (10%) Basic CVS commands (40%) Practical Issues in using CVS (50%)

My experience in real-life

For developers, not for maintainer

What is CVS?

What is CVS?

Concurrent Version Systems Two Major Purposes of using CVS

Keeping track of document history Allow concurrent development by

multiple developers

CVS is not RCS

It used many components of RCS. It doesn’t do file locking

A project manager You still need to manage your project.

The best in version control Many issues. We will see some of those. There are better , like subversion or bitkeeper

Change Logger You need to write your own log

Bug tracker You need to use other bug tracking software

So why do we use it?......

Many people used it. You could write it on your resume if

you knew it well Their web site is active

So there are documentation and places to ask questions.

It captured the spirit of concurrent version control software.

Basic CVS Walk-through

Life of a Project (in Practice) First initialization of a project (import) Development

“Download” the code (checkout) Know the status of the project

diff status, log history

Synchronize the code (update) Reverse the time flow (tag) Add and remove files (add and delete)

Cvs command general structure

General Syntax of cvs cvs [main options] commands

[command options] E.g. cvs –z3 checkout –D <date>

Download the code (checkout) Synonym : co CVSROOT : the variable name for the

repository syntax: cvs co <modulename> option –d

–d:<access method>:<username>@<repository> Access method

local (default) ext (use rsh or ssh) pserver (if cvs server is installed, not secured. Should not

be used. requires “cvs login”)

Checkout (cont.)

Practical problem 1 cvs DOES NOT version

directories Some directories can be empty

Solution: cvs checkout –P NOT check out empty directory

Check out in fife.speech.cs.cmu.edu

Detail instruction Install ssh and cvs setenv CVS_RSH ssh Check out: cvs

-d:ext:<username>@fife.speech.cs.cmu.edu:/home/CVS/ co <modulename>

<modulename> = mrcp.devel.v2 , CorpusTraining

Synchronize the code (update) After you change the code, you want to

synchronize with other people change. If not conflict.

M filename If there is a conflict

C filename If you got new update

U filename P filename if –z3 is specified.

Simple example of conflict

<<<<<<< falign.csh #hell no ======= #hell yes >>>>>>> 1.2 Demonstration

Options of update

-d , get new directory -l , only update things in local directory -C, get clean copies from the

repository Tricks : global command –n, will not do

anything in your repository. It is always good to have your own

copy!

Modules

By default, top level directories of the code

Special module : CVSROOT Also controlled by

CVSROOT/modules

Check in the code

cvs commit Specified you message using –m Or by default the editing will pop

up If there is conflict, cvs forbid you to

check-in the code.

Add new code

cvs add for text file cvs –kb add for binary files. Everything will SOMETIMES be

screwed up.

Remove code

rm file ; cvs delete file or cvs remove What if I want to recursively delete

everything? for i in `find . –name “*” –print |grep –

e CVS` ; do rm $i; cvs delete $i ; done

Check out code at a particular time.

Cvs co –D “2004-2-04” <module name>

Remember, time is not synchronized in practice!

Stickiness Stickiness for code

With previous time stamp With a specific tag

Sticky code cannot be committed to the latest trunk! Cvs doesn’t allow change of history

Solution: Cvs update –A Remove stickiness.

Tagging

Similar to cvs co –d Syntax

cvs tag <TAGNAME> Just give a symbolic meaning to a

particular time-stamp. Sticky operation. Remember to use

–A!

Getting Information

cvs status Knowing the version stickiness of the

filesFile: falign.csh Status: Up-to-date

Working revision: 1.5 Thu Jun 10 16:56:33 2004 Repository revision: 1.5 /net/elroy/usr1/archan/repository/res/test_script/falign.csh,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none)

Cvs log Know the history

So you know who to blame. ---------------------------- revision 1.5 date: 2004/06/10 16:56:45; author: archan; state: Exp; lines: +1

-1 HAHA ---------------------------- revision 1.4 date: 2004/06/10 16:42:41; author: archan; state: Exp; lines: +1

-0 hey hey ---------------------------- revision 1.3 date: 2004/06/10 16:20:55; author: archan; state: Exp; lines: +0

-1 test change

cvs diff

cvs diff file (Compare the local copy with the remote copy)

cvs diff –r 1.2 (Compare the local copy with the version 1.2)

cvs diff –r 1.2 –r 1.3 (Compare version 1.2 and 1.3)

Good for detectives……

Who do what ? Cvs history

Detail line-by-line report Cvs annotate

What we didn’t cover.

Advanced features What if we have external source of

code? What if we have multiple

repositories? Administration In “CVS Workshop II”

Real-life tasks From a programmer point of view, you

will want to, Check out the code, change it and check it

in back to the source base. Check out the code at a certain time

moment or with a certain tag. Merge n people source code (n>1)

The hell of a programmer Maintenance

A lot of issues

How to reduce the burden of merging?

Modularize the code Each module has its own

maintainer.

When should we check-in?

When you feel that it is “stable” Check List

Does your changes work? Does what you check-in affect other

people’s development? Changing function prototypes?

When should the code be stable?

Stable period Can be as short as 1 hour To as long as Infinity

Too short Programmers not able to sleep

Too long No one want to use CVS at all

How do we made everyone know the progress of the code?

CVS way (not recommended) cvs edit and watch

Loginfo Use syncmail

Two purposes of CVS revisited

Do you want to have the history? Stop the development and check-in

the code and merge the code. Do you want to keep multiple

people to work? Let them work separately, do merging

later.

Programmers in Real Life What you will learn in technical

management. Supervisor:

Problems : sometimes they have an MBA and think Java means coffee beans

Solutions : crystallize (or simplify) the concept of the project and explain to him.

Project Manager: Good one are valuable asset. Problems : too few of them are good.

Programmers in Real Life (cont.) Beginner:

Problems: know nothing Solutions: teach them

Hero/Star : save the day most of the time Problems :

always solo, so his knowledge doesn’t belong to the team.

Solutions: request/hope him to write more documents.

Programmers in Real Life (cont.) Hackers (Type H) : “hack the way out”-

type Problems : Revert some changes which is

important in long-term. Hackers (Type C) : “checker”-type, make

sure everything is correct/perfect Problems : No one can wait for them.

Hackers (Type T) : hacker who thinks Very valuable asset of a company Problems : There are not many of them in the

world. If they existed, they were undermined.

Programmers in Real Life (cont.) Theorist (Talker) : people who know/talk a

lot Problems : don’t do real work Solutions : kick him intelligently

Researchers : A type of theorist, always appear in high-tech company Problems : code are sloppy, doesn’t

generalize. It is not their main concern. They are quite slow from a normal developer point

of view. Solutions : Sometimes, they are fixable, that’s

why we need developers.

All these people can work with you! In CVS

Hero/Star: massive check-in, you need to take time to follow their footsteps

Hacker (Type H) and Researcher: monitor their changes.

Hacker (Type T) and Project Manager: he must have reasons, talk to him

Hacker (Type C) and Researcher: you need to wait for them.

Conclusion

CVS is just a tool You still need to manage a project. Question: Why CVS can always

make a team better? Not because of the software Because of the change of mind-set.