html5-img
1 / 39

CVS Workshop I

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

rianne
Download Presentation

CVS Workshop I

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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.

More Related