Subversion and Eclipse

This pages discusses the Subversion revision control system and, in particular, how it is used from within Eclipse. You will need to use Subversion for your group project. Therefore, you should read these pages carefully!

Introduction to Version Control

A version control system is primarily used to manage and co-ordinate software projects that are being developed by a team of programmers. The system acts as a central repository for the files being developed. The project is given a version number and, whenever a developer changes a project file, the version number is increased. This way, the system always keeps track of the latest version of the project.

Without Version Control

To understand the value of a version control system, consider two developers (Sally and Mark) working on a project (the Simple Lisp Interpreter) without using a version control system. Both Sally and Mark begin with identical copies of the source code (i.e. they both download the same simplelisp.jar file). Now, let's say Mark is working on the Interpreter package, and makes several improvements to the Java files there. At the same time, Sally is working on the Editor package and spends a lot of time improving the Graphical User Interface (i.e. the InterpreterFrame.java file).

At this point, Sally and Mark each have different versions of the Simple Lisp code; they want to merge them back together so they can see the improvements made by each other. The only way to do this is for Sally and Mark to send the files they have changed to the other person. This means they need to record exactly what changes they make when they make them. Otherwise, they may forget get to send an updated file to the other person.

There are several problems with this manual approach to version control:

1. A lot of time is spent recording exactly what changes a person makes.
2. It relies on the diligence of each programmer to record exactly what they have done. Forgetting a change can be catastrophic. Suppose Sally's part of the code uses some method in Mark's part of the code, but Mark forgets to tell Sally he's renamed the method. When Sally integrates Mark's changes, her version of the program will no longer compile. She might waste countless hours trying to figure out where she made a mistake, only to finally realise that Mark has made a change and told her.
3. If either Sally or Mark make some change and, later, decide that they want to undo this change, then this is very difficult unless they have kept regular backups of the integrated project. They need to hunt through these backups to find the unchanged version. Then, they need to integrate that back into the latest version. All of these things take time and, again, rely on programmer diligence to make regular back ups.
4. Suppose Sally finds a bug in Mark's code. Mark then hunts through his back ups to find the point at which the bug appeared. If he finds it, he might simply undo whatever change introduced the bug. What if the change he made was important for some reason? If he can remember why he made that change, then he'll know the answer. But, what if he made that change several months or years ago? If he logs every change made in a ChangeLog file, then he will be able to look back at why he made that change. Again, he needs to be diligent in recording every change in the log.

Each of the above points relies on the programmer to be diligent in what they do. If they forget something (which is easy to do when deadlines have to be met), then problems can arise later on in the project. Version control simply makes these things easier to do properly by automating many parts of the process and by making it easy to look back over what was done. Now, let's see how Sally and Mark could have used version control instead.

With Version Control

Sally and Mark begin by creating a repository for their project. This is the central place where all the files of the project are stored. The version control system will give the project a version number (say version 0 as the project is new). Now, when either Sally or Mark has made a change to some file they must commit that change to the repository. This means the system will upload the new file into the repository and increase the version number. However, the original version of the changed file is not deleted; instead, it is simply stored under the old version number. This means Sally or Mark can look back through the history and see the state of each file before and after every change made to the project.

Before the system commits a file to the repository, it will ask for a log message from the person making the change. This is attached to the new file, so that the log entry of every change can be seen. Every so often, Sally and Mark update their local version of the project. This means any changes made by the other person will be downloaded from the repository onto their machine, so they are always working on the latest version of the project.

The next tutorial will introduce Subversion and show you how to get started using it with Eclipse.

Related tutorials:

Introduction | Creating a Repository | Subversion Basics | Dealing with Conflict.