CVS & Version Control

1. CVS & Version Control Presenter: Eric Seidel ‘03, Math Major Part of the mini-course series: “The Liberal CS Major.” Brought to you by your LU CS Club

2. “The Liberal CS Major” Mini-Course series presented by the LU CS clubs to “fill the gaps” of the Lawrence CS Major Future Topics • Administering Apache, CS Club • Getting Around Linux/Unix, CS Club • BSD Socket Programming, CS Club • Topics in Networking, Robert Lowe

3. Tonight’s Outline • The Problems of Development • Understanding Version Control • The Solution that is Version Control • CVS: The Good/The Bad • Other Version Control Technologies • Further Information • Q&A

4. The Problems of Development

5. Development Scenario #1 You are writing a paper in collaboration with another person. You wish to allow them to make corrections to your work, while still allowing you to continue changing your copy of the work. You also wish to allow your editor to work on paper copies of your work which might be as much as a week behind your latest corrections, and still be able to benefit from his changes! Is this possible?

6. Development Scenario #2 You’re working on the 2.0 version of “your great app.” But 2.0 doesn’t quite compile yet… and customer finds a critical bug in 1.0, which must be fixed ASAP. If you're smart, you have a copy of your 1.0 source.You make the change and release, but how to you merge your changes into your 2.0 code? If you're not so smart, you have NO source code saved. You have no way to track down the bug, and you loose face until 2.0 is ready.

7. Development Scenario #3 Your working on a large scale development project. But you believe one of your team members has added malicious code to the project. How do you monitor what they’ve changed in your 10,000 line, or 100,000 line project? i.e. How do you add accountability to a text file?

8. The Answers It is these questions and more, that version control tries to answer. But before we answer them, lets look a little at how version control works…

9. Understanding Version Control

10. Terminology • SCM (Source Code Management) - Category of software including Version Control. • RCS (Revision Control System) - The father of SCM. • CVS (Concurrent Versions System) - The poster child for Version Control. • Repository - The central storage location for files under version control. • Workspace - Location of files “checked out” from a Version Control repository.

11. The General Idea • Version Control allows you a place to store your work as it progresses, and allows you instant recall of any work from any point in time. • It also can allow others to recall communal (or just your) work at any time, in a read only fashion, or also to make changes themselves.

12. Workspaces & Repository Your Workspace Cover.rtf (ver 1.2) Chapter 1.txt (ver 1.32) Chapter 2.txt (ver 1.20) Chapter 3.txt (ver 1.14) Repository Cover.rtf (ver 1.2) Chapter 1.txt (ver 1.32) Chapter 2.txt (ver 1.20) Chapter 3.txt (ver 1.15) Workspace Workspace Workspace

13. The Repository • The repository holds information including dates, labels, branches, versions, etc. • The repository holds just the changes between versions, saving space. • Also referred to as the a “depot” or “root” • Often held on a central server

14. Checkout & Commit Repository Cover.rtf (ver 1.2) Chapter 1.txt (ver 1.32) Chapter 2.txt (ver 1.20) Chapter 3.txt (ver 1.14) Checkout & Modify Workspace Cover.rtf (ver 1.2 - Modified) Chapter 1.txt (ver 1.32) Chapter 2.txt (ver 1.20 - Modified) Chapter 3.txt (ver 1.14) Chapter 4.txt (ver 1.1 - New) Repository Cover.rtf (ver 1.3) Chapter 1.txt (ver 1.32) Chapter 2.txt (ver 1.21) Chapter 3.txt (ver 1.14) Chapter 4.txt (ver 1.1) Commit

15. Checkout • With checkout commands, one can summon files or sets of files from the repository based on date, tag, branch, or any of a number of other criteria.

16. Update Workspace Cover.rtf (ver 1.2) Chapter 1.txt (ver 1.35) Chapter 2.txt (ver 1.21) Chapter 3.txt (ver 1.14) Repository Cover.rtf (ver 1.4) Chapter 1.txt (ver 1.35) Chapter 2.txt (ver 1.22) Chapter 3.txt (ver 1.18) Chapter 4.txt (ver 1.3) Update Workspace Cover.rtf (ver 1.4 - Updated) Chapter 1.txt (ver 1.35) Chapter 2.txt (ver 1.21 - Conflict) Chapter 3.txt (ver 1.18) Chapter 4.txt (ver 1.3 - New)

17. Update • Update commands will automatically bring your workspace up-to-date with the latest (or however you specify) files from the repository. • Update automatically merges non-exclusive changes between files and initiates conflict resolution if necessary. • Updates involving conflicts solicit information from the user how they wish to have a conflict resolve.

18. Simple Repository • Files are stored and associated with version numbers: 1.1 (or 1.1.1) for the first, and then 1.2 for the second revision, etc. • Only changes between files are stored. • Version numbers: 1.<branch>.<version> e.g. 1.2.1 for version 1 of a branch from 1.2

19. Branches • Branches break one set of code from another. • Are useful when “branching” before a release. • Are useful for testing experimental code. • Can be merged between branches or into the main trunk.

20. Tags • Tags associate multiple files and can be used to mark versions, printings, special dates, etc. • Developers can check out by tags • Tags can affect 1 or many files.

21. A More Complex Repository merge branch branch network.cpp

22. Diff Results • The Unix diff utility and built-in diff functionality in all SCM products allows you to see exactly what is different between any two files. • Great for finding changes causing bugs! [seidele-1:~/proj/math_book] cvs diff Chapter1.txt cvs server: Diffing Chapter1.txt 1c1 < Using our Monotone Convergence Theorem, we now see that y must tend to 2 as x approaches infinity. --- > Using our monotone convergence theorem, we now see that x must tend to 2 as y approaches infinity. cvs server: diff complete.

23. History Information • All SCM products provide some method by which a user can obtain the history of commands issued to the CVS server. • Useful for tracing who did what at the command level.

24. File Annotation • Allows you to see who changed what when, line by line. • Useful for tracking bugs. • Can be used in combination with diff and history for even more information.

25. Locking • Most SCM implementations provide a method by which you can “lock” files you are working on if necessary. Thus disallowing anyone else to commit changes before you have made yours. • Can be useful when writing prose - since changes tend to be more dramatic. • Useful when editing sensitive parts of code - users are forced to look at your changes before making theirs.

26. The Solution that isVersion Control

27. Development Scenario #1 You are writing a paper in collaboration with another person. You wish to allow them to make corrections to your work, while still allowing you to continue changing your copy of the work. You also wish to allow your editor to work on paper copies of your work which might be as much as a week behind your latest corrections, and still be able to benefit from his changes! Answer: Version Control

28. Scenario #1 Answers • If you and your collaborators use version control, you can each make changes to the same file have them merge, and be able to monitor what each other have changed. • You can also check out the same version from the repository that you printed for your publisher, make changes on that, and merge those into your most recent version.

29. Development Scenario #2 You’re working on the 2.0 version of “your great app.” But 2.0 doesn’t quite compile yet… and customer finds a critical bug in 1.0, which must be fixed ASAP. If you're smart, you have a copy of your 1.0 source.You make the change and release, but how to you merge your changes into your 2.0 code? If you're not so smart, you have NO source code saved. You have no way to track down the bug, and you loose face until 2.0 is ready. Answer: Version Control

30. Scenario #2 Answers • Using Version Control, you can commit and tag your releases. You are then able to recall the exact code your customer is using at any time. • Branches allow you to break off 1.x development, and later merge in the changes to benefit from your bug fixes. • Version Control also helps in tracking bugs. Maybe it was in 1.0.2, but not in 1.0.1? Good place to check is a 1.0.2 to 1.0.1 diff.

31. Development Scenario #3 Your working on a large scale development project. But you believe one of your team members has added malicious code to the project. How do you monitor what they’ve changed in your 10,000 line, or 100,000 line project? i.e. How do you add accountability to a text file? Answer: Version Control

32. Scenario #3 Answers • With diff and history functionality, you can track exactly what each of your contributors has done. • 3rd party tools such as Tinderbox from the Apache project help developers “blame” the right people for bugs, etc. • Using history functions, you can also prepare reports supporting how much (or little) effort you yourself have put into the project.

33. Other Common Uses • Websites are often kept in Version Control, especially when maintained by more than one person. • Individuals often use Version Control even for small projects to help with bug isolation, and to prevent “getting lost in ones own code.”

34. CVS: The Good / The Bad

35. About CVS CVS is the most popular, and one of the oldest forms of Version Control. CVS started as a bunch of shell scripts written by Dick Grune, posted to the newsgroup comp.sources.unix in December, 1986. Much of the current CVS conflict resolution algorithms are derived from those scripts. In April, 1989, Brian Berliner designed and coded CVS in C. Jeff Polk later helped Brian with the design of the CVS module and vendor branch support. CVS has since grown to be the de facto standard for version control, despite a raft of design problems. CVS is open source and is maintained by developers at http://www.cvshome.org/

36. The Good • Extremely Popular • Free & Open Source • Simple & Effective • Ships on nearly every Linux/Unix OS • Many 3rd party tools designed for CVS • A good start to Version Control • Long history http://www.cvshome.org/

37. Maintains NO file meta-data Serving was an afterthought Poor Branching Poor Permissions No “change sets” Non Atomic Security was an afterthought Slooooooower than molasses Single Repository No language support Only supports ASCII Text (not Unicode) The Bad http://www.cvshome.org/

38. Other Version Control Technologies

39. Good Free & Open Source Designed to serve Host of improvements on CVS Fast Partially CVS Compatible Bad Apache dependant Still in 0.15 Beta Subversion http://subversion.tigris.org/

40. Good Free to Open Source High performance Great support Partially CVS Compatible Bad $$ Expensive Bigger & more complex than CVS Single Repository Perforce http://www.perforce.com/

41. Other Products • BitKeeper - http://www.bitkeeper.com/ • VOODOO Server- http://www.unisoftwareplus.com/ • ClearCase - http://www.rational.com/ • RCS (Revision Control System) -http://www.gnu.org/software/rcs/rcs.html • Sun Forte/Teamware - http://www.sun.com/

42. Further Information

43. Web Resources • http://www.cvshome.org/ • The Home of CVS • http://subversion.tigris.org/ • Subversion Home • http://www.perforce.com/ • Perforce Home • http://developer.apple.com/techpubs/macosx/DeveloperTools/cvs/cvs_stoc.html • Apple’s guide to using CVS.

44. Web Resources (cont) • http://www.wincvs.org/ • A CVS GUI • http://www.mozilla.org/{tinderbox,bonsia}.html • Two CVS related tools. For kicks, just go to mozilla.org and look at tree status. Then you’ll understand the real use of Version Control. • http://www.gnu.org/ • The father’s of Free Software (as in speech). And tools such as RCM.

45. Conclusion • Version Control tools such as CVS can be immensely helpful to developers and writers. • SCM is mandatory in real world development. • Hopefully you have at least a beginning idea of how Version Control might be helpful to you in your work.

46. Q & A Eric Seidel ‘03 Eric.C.Seidel@lawrence.edu

48. Credits • Parts of “About CVS” paraphrased from the CVS Manual @ http://www.cvshome.org/ • Graphs made with OmniGraffle from http://www.omnigroup.com • All other text is original work by the author. • Those wishing to reproduce, or represent this work, are free to do so, and are asked as a curtousy to notify the author Eric.C.Seidel@lawrence.edu if possible.