Today’s Agenda

1. Today’s Agenda • CVS • GDB

2. What is CVS? • CVS is a version control system. • Allows retrieval of old versions of projects. • Reduces the need for communication between developers to coherently maintain files. • Stores all the versions of a file in a clever way that only stores the differences between versions.

3. What CVS cannot do... • Not a build system. • Not a substitute for management. • Not a substitute for developer communication. • Does not have change control. • Not an automated testing program. • Does not have a built-in process model.

4. File Management without CVS Dev_1 Project Files Dev_2 Dev_3

5. File Management with CVS Dev_1 Project Files Dev_2 Dev_3

6. Basic Concepts • All files stored in a central repository. • Each version of a file has a unique revision number. • (e.g. 1.1, 1.2, 1.3.2.2) • always contains even number of digits. • CVS is not limited to linear development.

7. An Example engine.c util.c window.c 1.1 1.1 1.1 prjv1 (tag) 1.2 1.2 1.2 1.3 1.3 1.3 prjv2

8. What is a tag? • A symbolic name given to a file revision or more typically a set of file revisions. • Tags can be used to represent versions of an entire project. • Should be used at strategic points in the development cycle.

9. Non-linear development prjv1 prjv2 prjv3 prjv4 b1 b2 prjv1_fixes (branch)

10. Why would I use a branch? • Allows for maintenance of bug fixes. • Provides means to backtrack and create experimental versions of a project. • Scenario: already tagged 3 versions of project. And users complain about bug in version 1 -- what do you do?

11. Okay, how do I use this? • Creating the CVS repository. • setenv CVSROOT /usr/u/warkhedi/cvsroot • cvsinit • Assume project files in project directory. • Adding directory structure to CVS. • cd project • cvs import trialprj NONE INITIAL

12. Here is how it looks... /usr/u/warkhedi/cvsroot trialprj engine.c,v util.c,v window.c,v

13. Check in, Check out. • Checking out files in repository. • cvs co -d project1 trialprj • Creates files in project1 directory. • Notice CVS directory in project1. • E.g. modify engine.c • Checking in changes. • cvs commit • Only engine.c is checked in.

14. Updating my copy engine.c 1.1 engine.c 1.2 engine.c 1.3 local copy engine.c 1.1 (*) update commit engine.c 1.3 (U) engine.c 1.4

15. 3 Possibilities at an Update • If local file is un-modified: • CVS updates local copy with the latest. • U engine.c • If local file is modified: • CVS attempts to merge the two files, textually. • If there is conflict (defined as change on same line), modify local file to indicate this else merge the two files quietly.

16. Let’s play tag... • Tag all files at a strategic point in time. • cvs tag -R prjv1 . • Tagged files can have different revision numbers. • Later, the project version 1 can be checked out. • cvs co -r prjv1 -d project1 trialprj • remake to get object files for version 1.

17. Creating Branches • cvs rtag -b -r prjv1 prjv1_fixes trialprj • CVS command rtag creates new tag in the repository. • Branch prjv1_fixes is spawned from tagged files of prjv1. • Bug fixes can be made on prjv1_fixes and subsequent branch versions can be merged later.

18. Sticky tags • All subsequent commands operate on the tag. • cvs co -r prjv1 -d project1 trialprj • when you checkout with a specific tag, all files have a sticky tag. • cannot commit files with sticky tag. • Exception: branches. • Use update -A to eliminate sticky tags.

19. An Example • cvs co -r prjv1 -d project1 trialprj • modify util.c • cvs commit • tries to commit to prjv1 • cannot commit changes to prjv1

20. Another Example • cvs co -r prjv1_fixes -d project1_fixes trialprj • modify util.c • cvs commit • tries to commit to branch prjv1_fixes • works! makes sense.

21. Merging Branches • cvs co -d latest trialprj • cd latest • cvs update -j prjv1_fixes • merges all changes in the branch into the latest copy. • cvs commit • all fixes incorporated into the mainline.

22. Adding/Deleting Files • Adding a file to the repository. • cd project1 • cvs add mem.c • project1 must have CVS directory. • Removing a file from the repository. • cd project1 • cvs remove mem.c

23. Status Checking • cvs status • provides complete information on all files in a directory • e.g. revision #s, stick tag, etc. • cvs diff • displays difference between the working version and the repository version. • diffs all files in the current directory.

24. Lot more options available!! • Features discussed so far are most commonly used. • Feel free to explore others too. • Start experimenting now.

25. GDB • Vanilla debugger. • XGDB - graphical version of GDB • Visual Studio debugger.

26. What is a debugger? • Allows you to debug. Duh! • More specifically... • can step through code, set breakpoints, watch variables, examine structures, etc. • Source-Level debuggers. • allow user to visually interact with source code. • Assembly-Level debuggers. • well, they are just a pain to use.

27. Example include <stdio.h> #include <stdlib.h> void main() { int x, y, z; x = 0; y = 0; while (x <= 5) { x++; y = y + x; z = sqr(y); printf("%d ", z); } printf("\n"); } int sqr(int x) { int y; return(y); }

28. Continued... • Compile program with -g option to include symbolic info. • gcc -g test.c • gdb a.out • break 7 -- sets breakpoint at line 7. • run -- runs the program. • Program stops at line 7.

29. Continued... • step -- steps one source line. • watch x -- displays variable x upon change. • break sqr -- sets breakpoint on sqr() • continue • program displays change in x.

30. Continued... • continue • program stops in sqr() • up -- goes up to main stack frame. • down -- back down to sqr() • step and print y -- displays value of y. • delete 1 -- deletes breakpoint 1

31. Finally... • continue -- runs the program till the end. • watch is deleted when out of scope.

32. Other useful features • next command • steps over an entire function. • finish command • execute until current stack frame returns. • And plenty others at your disposal!!