Version Control with CVS

1. Version Controlwith CVS Peter Dinda Department of Computer Science Northwestern University

2. What is Version Control? • Go back in time • Undo nasty mistakes by you or others • Coordinate among multiple developers • Avoid stepping on each others toes • Also for working on multiple machines • Me: desktop, laptop, home machine • Collective model of the “project” • Including multiple variants

3. What does it look like? The “Repository” All Versions of all the files Alice’s Local Version Joe’s Local Version Jane’s Local Version

4. What does it look like? The “Repository” All Versions of all the files Add a new file (or directory) that everyone can see “OK” or “File already exists” Alice’s Local Version Joe’s Local Version Jane’s Local Version

5. What does it look like? The “Repository” All Versions of all the files Commit my changes so everyone can see them “OK” or “Your files are out of date” Alice’s Local Version Joe’s Local Version Jane’s Local Version

6. What does it look like? The “Repository” All Versions of all the files Update my local files to reflect all changes “OK” or “Your files conflict” Alice’s Local Version Joe’s Local Version Jane’s Local Version

7. What does it look like? The “Repository” All Versions of all the files Call what I have “Release 1.0” “OK” Alice’s Local Version Joe’s Local Version Jane’s Local Version

8. What does it look like? The “Repository” All Versions of all the files Create a separate version: “Release 1.0.joe” for local testing “OK” Alice’s Local Version Joe’s Local Version Jane’s Local Version

9. What does it look like? The “Repository” All Versions of all the files Six Months Later Merge my special version back into the main product “OK” Alice’s Local Version Joe’s Local Version Jane’s Local Version

10. What does it look like? The “Repository” All Versions of all the files One Year Later Release 1.5-Joe causes injuries! Give me “Release 1.0” “OK” Alice’s Local Version Joe’s Local Version Jane’s Local Version

11. How do I get it? • CVS • Free, works on Windows, Linux, Unix, etc. • Used a LOT, but has assorted cruft • Subversion • Free, works on Windows, Linux, Unix, etc. • “A better CVS” – same commands, uses our old friend, Mr. Transaction, on top ofBerkeleyDB • Others (pay) • Visual Source Safe (MS) • Perforce (very highly regarded) • Generally pay to get better branching support

12. CVS The Easy Way • Linux or Unix box • Probably already installed. Run “cvs”. • export EDITOR=“xemacs –nw” • Default EDITOR is typically vi • Windows box • Just install cygwin – it will just work • Various command-line and GUI-based cvs clients are also available

13. Do I need a special server? • No. You just need a directory that’s accessible by all the developers. • export CVSROOT=/home/pdinda/MYCVS • No. Even if you want to use a remote machine, just use ssh: • export CVS_RSH=ssh • export CVSROOT= :ext:pdinda@tlab-login:/home/pdinda/MYCVS • No. Even if you have multiple developers, just use Unix groups and the group sticky bit • chown pdinda.mycvsgroup /home/pdinda/MYCVS • chmod g+s /home/pdinda/MYCVS • No. Don’t bother with “pserver” and “kserver” unless you need them. • You almost certainly do not

14. Getting CVS Help • cvs –help-commands • Does what you might expect • cvs –H command • Tells you the details of the command • There are lots of CVS commands. You only need to use a few: init, import, add, remove, checkout, commit, update, tag

15. Initializing the Repository • Only done once • cvs init • Creates directory and initial files

16. Bringing a directory (module) into CVS • cd btree_lab • cvs import my_btree_lab PDINDA PDINDA0 • my_btree_lab – what I’m going to call it • PDINDA – my “Vendor tag” • PDINDA0 – my “Vendor release tag” • IMPORTANT: btree_lab is *NOT* under the control of CVS. We must check out my_btree_lab first!

17. Checking Out a Module • cvs checkout my_btree_lab • cd my_btree_lab • (start working)

18. How do I add files and directories? • cvs add filesanddirectories • cvs add –kb file • the file is binary • Most clients figure this out themselves, but it’s a good habit to have

19. How do I remove files and directories? • cvs remove fileordirectory • “I don’t want cvs to manage this any more” • cvs remove –f fileordirectory • “Not only should it not manage it, but delete my local copy too.” • Note that remove and add affect the REPOSITORY. • Recovery: The “Attic”

20. How do I commit? • cvs commit [files] • You may get “up to date check failed for..” • This means you need to update those files first and fix any conflicts before you can commit. • Note that add/remove/edits/etc DO NOT GET REFLECTED IN THE REPOSITORY UNTIL YOUR COMMIT IS SUCCESSFUL

21. Getting Updates From The Repository • cvs update [-d] [files] • -d => Get new subdirectories! • if files are not specified, everything in this directory and its subdirectories is updated

22. Understanding Updates • An update MERGES the version of the file that’s in the repository into the one on your disk • You have A • Repository has B • After update, you have MERGE(A,B) • Merges are not always possible automatically. • CVS punts to you if this happens, reporting a conflict • You have to resolve the conflict yourself • This is uncommon in most development because different developers are working on different files

23. What Versions do I have? • cvs status [files] • Each file and directory has a version number. • 1.1, 1.2, … (first level) • 1.1.1.1, 1.1.1.2, … (one level branch)

24. What are all the versions? • cvs log file • cvs rlog module (directory)

25. How can I give versions names? • Current version: • cvs tag name files • cvs rtag name module • Other versions: • cvs tag –r version … • cvs rtag similar

26. How do I go back in time? • cvs update –r version file • cvs update –r tag file • cvs update –D datetime file • This makes the file “sticky”, meaning that subsequent updates will not move it to a newer version • You can update out of the sticky version by using cvs update –A

27. Branching • So far, we’ve treated each file/directory as having a sequence of versions (1.1, 1.2, etc) • CVS lets you have parallel versions, turning the version “linked list” into a version “tree”. • In theory, very useful for when one wants to take a large project and create a “side project” without affecting the main line of development

28. Merging • Versions are actually DAGs. You can take your “side project” version and merge it back into the mainline of development. • This all sounds awesome, but…

29. Branching/Merging has Problems • Branching is easy, but merging is hard • CVS basically gets this wrong • And the problem is compounded because IT DOES NOT USE TRANSACTIONS FOR ANYTHING • It also doesn’t really provide any tools for dealing with merge conflicts. • So, a merge can end up half done! Blam: your project is in big trouble. • Lack of transactions also bites you for updates and commits.

30. CVS Branch/Merge Advice • Don’t use it. • Don’t use it. • Don’t use it. • If you MUST use it, spend a lot of time making sure you understand it first. • Buy a tool that supports this well^Wbetter if you need it.

31. Stupid Windows/Unix Issues • Windows ends lines with \r\n • Sometimes likes to use Unicode too • Unix ends lines in \n • And uses ASCII pretty much all the time • CVS is line-oriented • End result: be very careful in setting up your client on the foreign platform. Lots of web help on this, however.

32. Subversion • An attempt to build a tool that has CVS’s command set but does not suffer from its problems • “svn” is the command • Big one: Transactions used throughout • Assorted bugs/misfeatures of CVS fixed in a way that is sensible • Looks pretty good. We’re using it for developing a class. • But I’m pretty happy with CVS too

33. For More Info / Downloads • CVS: http://www.cvshome.org/ • Subversion: http://subversion.tigris.org/ • Free Book: http://svnbook.red-bean.com/ • Perforce: http://www.perforce.com/ • VSS: http://www.microsoft.com