CVS Workshop I

1. CVS Workshop I Arthur Chan

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

3. What is CVS?

4. What is CVS? • Concurrent Version Systems • Two Major Purposes of using CVS • Keeping track of document history • Allow concurrent development by multiple developers

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

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

7. Basic CVS Walk-through

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

9. Cvs command general structure • General Syntax of cvs • cvs [main options] commands [command options] • E.g. cvs –z3 checkout –D <date>

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

11. Checkout (cont.) • Practical problem 1 • cvs DOES NOT version directories • Some directories can be empty • Solution: cvs checkout –P • NOT check out empty directory

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

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

14. Simple example of conflict • <<<<<<< falign.csh • #hell no • ======= • #hell yes • >>>>>>> 1.2 • Demonstration

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

16. Modules • By default, top level directories of the code • Special module : CVSROOT • Also controlled by CVSROOT/modules

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

18. Add new code • cvs add for text file • cvs –kb add for binary files. • Everything will SOMETIMES be screwed up.

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

20. Check out code at a particular time. • Cvs co –D “2004-2-04” <module name> • Remember, time is not synchronized in practice!

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

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

23. Getting Information • cvs status • Knowing the version stickiness of the files File: 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)

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

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

26. Good for detectives…… • Who do what ? • Cvs history • Detail line-by-line report • Cvs annotate

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

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

29. How to reduce the burden of merging? • Modularize the code • Each module has its own maintainer.

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

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

32. How do we made everyone know the progress of the code? • CVS way (not recommended) • cvs edit and watch • Loginfo • Use syncmail

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

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

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

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

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

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

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