Using Source Code Versioning & Management Tools
NRCFOSS 1 diff
• The diff program compares two versions of a document, generating a set of differences that reflect the changes that need to be applied to the old document to make it identical to the new document diff –c orig/file newfile > changes.txt
NRCFOSS 2 patch
• The set of differences can be transported to someone who has the original copy of the document. By running the patch program, the document contents can be updated to the new version cd orig patch < changes.txt
NRCFOSS 3 Why diff and patch is not sufficient for Version Control • A submission was incorporated into the sources and had to be removed later because it contained flaws • By that time, it was hard to figure out who applied what patch when • Even if programmers could track down the change, manually undoing the effect of a patch long after the fact is a tedious and error-prone process • The solution was a system for keeping track of a project’s history—one that allowed the retrieval of previous versions for comparison with the present version.
NRCFOSS 4 Revision Control
• Revision control is any practice which tracks and provides controls over changes to source code • As software is developed and deployed, it is extremely common for multiple versions of the same software to be deployed in different sites, and for the software's developers to be working privately on updates. • Bugs and other issues with software are often only present in certain versions (because of the fixing of some problems and the introduction of others as the program evolves)
NRCFOSS 5 Revision Control ...
• Therefore, for the purposes of locating and fixing bugs, it is vitally important for the debugger to be able to retrieve and run different versions of the software to determine in which version(s) the problem occurs. • It may also be necessary to develop two versions of the software concurrently (for instance, where one version has bugs fixed, but no new features, where the other is where new features are worked on)
NRCFOSS 6 Access by Multiple Developers
• Another problem that occurs in large software development projects is that of multiple developers seeking to work on the program at the same time • If two developers try to change the same file at the same time, without some method of managing access the developers may well end up overwriting each other's work
NRCFOSS 7 Source Code Versioning software
• To control and manage the different versions of the source code files, a variety of software are available as Free/Open Source Software • Basically they can be classified as: – those using a distributed approach (e.g. GNU Arch, Codeville) – those that are using non-distributed approach (RCS, CVS, Subversion)
NRCFOSS 8 Proprietary Version Control Software • Bitkeeper (was used in Linux Kernel development from Dec 1999 to April 2005) • Clearcase (widely used in the Corporate environment) • SCCS – Source Code Control System (part of UNIX) • Microsoft Visual Source Safe
NRCFOSS 9 What is CVS?
• CVS stands for Concurrent Versions System and is a widely used version control system for FOSS development • It started out as a bunch of shell scripts written by Dick Grune, posted to the comp.sources.unix in vol.6/July/1986. • No actual code from these shell scripts is present in the current version of cvs, much of the cvs conflict resolution algorithm come from them
NRCFOSS 10 CVS History continued
• In April 1989, Brian Berliner designed and coded cvs • Jeff Polk later helped Brian with the design of the cvs module and vendor branch support • Can be downloaded from http://www.cvshome.org
NRCFOSS 11 What CVS is not?
• CVS is not a build system • CVS is not a substitute for management • CVS is not a substitute for developer communication • CVS does not have change control • CVS is not an automated testing program • CVS does not have built-in process model • Not the Lock-Modify-Unlock Model
NRCFOSS 12 What is CVS for?
• CVS maintains a history of a source tree, in terms of a series of changes. • It stamps each change with the time it was made and the user name of the person who made it. • Usually, the person provides a bit of text describing why they made the change as well. • Given that information, CVS can help developers answer questions like: – Who made a given change? – When did they make it? – Why did they make it? – What other changes did they make at the same time? • Follows Copy-Modify-Merge Model
NRCFOSS 13 How CVS works?
• CVS stores files in a central repository, to be accessible to all users of the files. • Commands are given to "check out" a copy of a file for development, and "commit" changes back to the repository. • It also scans the files as they are moved to and from the repository, to prevent one person's work from overwriting another's.
NRCFOSS 14 client side usage of CVS
NRCFOSS 15 Setting up the repository
• CVS records everyone's changes to a given project in a directory tree called a repository. • Before you can use CVS, you need to set the $CVSROOT environment variable to the repository's path • e.g. In Bash shell, it can be done as: CVSROOT=/u/src/master export CVSROOT
NRCFOSS 16 Setting up repository...
• If you forget to do this, CVS will complain when you try to use it: $ cvs checkout httpc cvs checkout: No CVSROOT specified! Please use the `-d' option cvs [checkout aborted]: or set the CVSROOT environment variable.
NRCFOSS 17 The Repository
• The cvs repository stores a complete copy of all the files and directories which are under version control • cvs repository can be either local or remote, which can be identified with an access method • The format of the repository name is: [:method:][[user][:password]@]hostname [:[port]]/path/to/repository
NRCFOSS 18 Example of using repository name
• :local:/usr/local/cvsroot means that • the repository is in ‘/usr/local/cvsroot’ • on the computer running cvs • /usr/local/cvsroot • :local:c:/src/cvsroot (on windows) • :ext:[email protected]:/h ome/cvs
NRCFOSS 19 CVS related Environment Variable
• $CVSEDITOR • $EDITOR • $CVSROOT • $CVS_RSH
NRCFOSS 20 • Checking out a working directory • Making changes to files • Merging the changes • Committing the changes • Examining changes • Adding and Deleting files • Writing log entries • Handling Conflicts
NRCFOSS 21 Checking out a working directory
• CVS doesn't work on ordinary directory trees; you need to work within a directory that CVS created for you. • Just as you check out a book from a library before taking it home to read it, you use the cvs checkout command to get a directory tree from CVS before working on it.
NRCFOSS 22 checkout
• For example, suppose you are working on a project named httpc, a trivial HTTP client: $ cd $ cvs checkout httpc cvs checkout: Updating httpc U httpc/.cvsignore U httpc/Makefile U httpc/httpc.c U httpc/poll-server
NRCFOSS 23 checkout ...
• CVS puts the tree in a subdirectory named `httpc': $ cd httpc $ ls -l total 8 drwxr-xr-x 2 jimb 512 Oct 31 11:04 CVS -rw-r--r-- 1 jimb 89 Oct 31 10:42 Makefile -rw-r--r-- 1 jimb 4432 Oct 31 10:45 httpc.c -rwxr-xr-x 1 jimb 460 Oct 30 10:21 poll-server • CVS uses the directory “CVS” to record extra information • about each of the files in that directory, to help it determine what changes you've made since you checked it out.
NRCFOSS 24 Making changes to file
• Once CVS has created a working directory tree, you can edit, compile and test the files it contains in the usual way -- they're just files. • For example, suppose we try compiling the package we just checked out: $ make gcc -g -Wall -lnsl -lsocket httpc.c -o httpc httpc.c: In function `tcp_connection': httpc.c:48: warning: passing arg 2 of `connect' from incompatible pointer type
NRCFOSS 25 Merging the changes
• Let’s assume we modified line#48 and corrected the error in that function call • Since each developer uses their own working directory, the changes you make to your working directory aren't automatically visible to the other developers on your team. • CVS doesn't publish your changes until you're ready.
NRCFOSS 26 why update before commit?
• When you're done testing your changes, you must commit them to the repository to make them available to the rest of the group. • What if another developer has changed the same files you have, or the same lines? Whose changes should prevail? It's generally impossible to answer this question automatically; CVS certainly isn't competent to make that judgment.
NRCFOSS 27 update
• Before you can commit your changes, CVS requires your sources to be in sync with any changes committed by the other team members. The cvs update command takes care of this: $ cvs update cvs update: Updating . U Makefile RCS file: /u/src/master/httpc/httpc.c,v retrieving revision 1.6 retrieving revision 1.7 Merging differences between 1.6 and 1.7 into httpc.c M httpc.c
NRCFOSS 28 precaution after update
• Always check whether your code is still working after an update since it now contains somebody else modifications also • Once you are sure, it works, then you can commit the changes to the repository • Before committing, it's always safe to run cvs update to get a list of the modified files from CVS: $ cvs update cvs update: Updating . M httpc.c
NRCFOSS 29 commit
$ cvs commit httpc.c • At this point, CVS will start up your favorite editor and prompt you for a log message describing the change. When you exit the editor, CVS will commit your change: Checking in httpc.c; /u/src/master/httpc/httpc.c,v <-- httpc.c new revision: 1.8; previous revision: 1.7
NRCFOSS 30 Examining the log entries
• For a given file, the log entries can be examined using: $ cvs log httpc.c
NRCFOSS 31 changes between two revision
• To see the changes made between two different version, use: $ cvs diff -c -r 1.6 -r 1.7 httpc.c
NRCFOSS 32 Adding files
• To add a file to a project, you must first create the file, and then use the cvs add command to mark it for addition. Then, the next call to cvs commit will add the file to the repository cvs add myfile.c cvs commit myfile.c
NRCFOSS 33 Removing files
• If you delete a file and then run cvs update, CVS doesn't assume you intend the file for deletion. Instead, it does something benign -- it recreates the file with its last recorded contents, and flags it with a `U' character, as for any other update. (This means that if you want to undo the changes you've made to a file in your working directory, you can simply delete the files, and then let cvs update recreate them.) • To remove a file from a project, you must first delete the file, and then use the cvs rm command to mark it for deletion. Then, the next call to cvs commit will delete the file from the repository.
NRCFOSS 34 Book on CVS
• Open Source Development with CVS, 3rd Edition, by Moshe Bar, Karl Fogel (This book is available online in PDF format under GNU GPL) http://cvsbook.red-bean.com/OSDevWithCVS_3E.pdf • Version Management with CVS, Per Cederqvist et.al. (Official CVS manual) https://www.cvshome.org/docs/manual • An Introduction to CVS by Jim Blandy https://www.cvshome.org/docs/blandy.html
NRCFOSS 35 Bug Tracking System
NRCFOSS 36 Bug Life Cycle
• Bug is identified in the software and reported (entered) in the bug tracking system (BTS) • BTS will allow a bug to be assigned to a developer • Developer resolves bug or clarifies with user • Developer sets bug to “Completed” status and assigns back to original user
NRCFOSS 37 Bug Life Cycle ...
• Original user verifies that bug has been resolved and if so sets bug to "Closed" status. • If the bug was not resolved to the user's satisfaction they may assign it back to the developer with a description (by adding a new detail). If this occurs then the bug returns to step (2) above.
NRCFOSS 38 Bug Tracking System Features
• Bug Change Histories • Version Control Integration • Customizable Fields • Email notifications • Provision to add trace files and attachment • Report Generation • Security • Web based client
NRCFOSS 39 Bug Tracking System
• Example Open Source BTS – Bugzilla http://www.bugzilla.org – Flyspray http://flyspray.rocks.cc
NRCFOSS 40