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

10. Download the code (checkout) Synonym : co CVSROOT : the variable name for the repository syntax: cvs co option –d –d: : @ 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: @fife.speech.cs.cmu.edu:/home/CVS/ co = 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” 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 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.