Introduction

For the next homework, you will create your project in a more real-world way using a version control system.
We will use GIT to do version control.
Today, we are going to look at different kinds of version control systems and how bug/issue tracking is handled.
I will use the term bug in a very flexible sense: It might mean a software defect that needs to be fixed, it might mean a software enhancement that is desired.

Version Control Systems

A version control system solves the problem of how many people can work on the same code base at the same time.
There are many different such systems on the market, the oldest is Source Code Control System developed at Bell Labs in 1972.
It was subsequently supplanted in popularity by RCS (Revision Control System) which in turn was supplanted by CVS (Concurrent Version System).
Nowadays, there are many different versions control systems on the on the market.
There are traditional central repository systems: CVS, Subversion (open source); BitKeeper, Perforce, ClearCase ( proprietary)
There are also distributed version control systems: Bazaar, git, Mercurial.
Here is a round-up of the different features of these systems http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
We are going to look at an example of each of these major type of systems.
We will look at Subversion because: (a) it uses http and https as its means of accessing the repository; (b) it is open source and has been around along enough that it seems for real; and (c) According to Eclipse Community Survey 2010, at least among Eclipse user's it has a 58% market share (CVS has about 20%).
In comparison, GIT has a 7% share and is currently the most popular distributed version control system.
Today, we will talk about Subversion on Wednesday we will talk about Git.

Quiz

Which of the following statements is true?

Prepared statements allow you to execute the same SQL query with different bound in parameters without the DBMS needing to recompile the statement each time.
The cookie protocol is implemented by your browser communicating with a cookie server on Port 3306.
Boyce Codd Normal Form says a table should not have any trivial functional dependencies.

Subversion

Subversion was created in 2000 by CollabNet, Inc.
To get subversion (it often comes with *nix systems) you can go to:
http://subversion.apache.org/
A manual for subversion can be found:
http://svnbook.red-bean.com/nightly/en/index.html
I'll often call Subversion svn.

Setting up your Repository

Common ways to set up svn on a network are to use the svnserve that comes with it or to use Apache.

To begin though, we probably just want to experiment with creating a repository on our local machine, which can be done with a lines like:

svnadmin create /path_to_repository
svn co repository_uri local_dir ; cd local_dir
#svn import trunk file:///path_to_files_want_in_initial_repository
#if importing from a different repository
svn mkdir trunk #don't do if did above
svn mkdir branches
svn mkdir tags

Trunk, Branches, Tags

The organization above is not mandatory; however, it is a common way to organize an svn repository.
Basically, the trunk directory is used to hold the main version of your code.
Incremental work on the code is usual done and maintained in trunk.
If someone needs to implement a large feature which might make everything not work until it is ready, then they might create branches from trunk and work on those.
Often it is useful to have "frozen versions" of the code base which are known to be completely working and don't change much.
You might use the tags directory for these. For instance, you might maintain a production tag.

Basic Work Cycle

Typically, a programmer who is going to work on a bug, checks out a version of the repository:

svn checkout url_or_path_to_repository local_dir
Or
svn co url_or_path_to_repository local_dir

This makes a copy of the repository in local_dir.
If we cd into local dir, we can see what's there by typing the command:
```
svn list
```
If you actually do an ls -a on the directory in question, you will see there is a hidden directory .svn in each subdirectory of your local copy. This is how svn keeps track of what things have been updated.
You can now edit the files to fix your bugs using whatever editor you like (such as vi).
While you are making changes on your local system, other people might be committing revisions to the repository, to keep in sync with these revisions, you can do:
```
svn update
 or
svn up
```

More Basic Work Cycle

svn up will get the most recent versions of files you haven't changed from the repository into your local store, it will try to merge the changes in the files you have changed with those in the repository again outputting to your local store, finally, it may say there is a conflict on some files which svn couldn't resolve.
For the conflict files you need to look at the files and fix the conflict. Once its fixed you can type:
```
svn resolved filename_with_conflict.
```
You can then check in your code (this make your changes take effect in the repository rather than your local copy) with a line like:
```
svn ci -m "Fixes BugXXXX, r=so-and-so, a=someone-else" 
```
so-and-so is the person who reviewed the patch, someone-else is the person who approved the check-in. You often only have r= or a= but not both.

Add, Delete, Diff

Sometimes in fixing a bug, you need to add a file to the local copy of the repository.
After you have made the file in the editor, you can then tell svn to add it to the local copy using a line like:
```
svn add filename
```
Similarly, sometimes you might need to delete a file from the local copy of the repository:
```
svn delete filename 
```
Sometimes you need to create a patch consisting of your changes to the repository. This could then be reviewed by someone else.
```
svn diff  > my_patch.txt
```
Someone could then apply the patch by checking out the code from the repository and then doing a line like (in the correct directory:
```
patch -p0 < my_patch.txt
```

Issue Tracking

Typically, you would post patches you make to some kind of bug/issue tracking tool for review before they are checked-in.
Some popular Bug/Issue tracking tools are: JIRA (17% share), Bugzilla (15.3%), Trac (10.3%).
An issue tracking tool completely written in PHP is MantisBT (9.1%).
Here is a list of other tracker that exist: http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems

svn copy, merge

Creating a tag and a branch are essentially the same thing:
```
svn copy trunk_url  prod_url -m "Create production tag"
```
If trunk changes and you want to incorporate the changes into production one can, check out a copy of production and do a line like:
```
svn merge -r###:HEAD trunk_url branch_name
```
then commit the result.
If you don't want to emphasize from which version to which you can leave off -r###:HEAD
To reintegrate a branch with trunk, you check out trunk, and do a line like:
```
svn merge -r###:HEAD branch_url trunk
```
on the local copy, then commit the result.

Creating and Administering a Web Development Environment

Outline