Subversion is an open-source version control tool that is superior to CVS. Find out which CVS flaws Subversion rectifies, and see how easy it is to start using this highly useful tool.

WEBINAR:

On-Demand

Subversion in the Development Process
For now, move on to creating some actual project files and seeing how to work with Subversion in the development process. First, clean up:

cd ..
rm –fr first-project

Once you have committed your changes, you can delete the working copy. If you plan to make further changes, you can leave the working copy and just make your changes in it. Normally, you would leave your working copy, but you will check out a different directory before creating some code files that you will add to the project. Issue the following commands:

Note the difference: you just checked out the trunk, but told Subversion to put it in a directory called "first-project". The trunk is where active development should occur most of the time. The "co" is shorthand for "checkout". For a list of shorthand, type "svn help". You created three code files. The touch command simply updates the timestamp on a file, creating the file if it does not exist. This tutorial used it simply as a quick way to create the three Java source files, which are zero byte files. Obviously in your development sessions, you will create code in the Java source files rather than leaving them as zero byte files. The "svn add" command tells Subversion that you want to add a file (or multiple files specified by a wildcard) to the repository for version control.

The reason you issued the "svn update" command is that it is important to resolve conflicts before checking in your changes. In fact, Subversion will not allow you to commit your changes if you are not up to date. The commit operation will abort and roll back. Subversion will tell you that your working copy is out of date. When you perform the update, Subversion may update some of your files with no conflicts. Other files may have conflicts (e.g., you tried to change a section of code that another person also tried to change). In cases of conflict, you must resolve the conflict before committing. You will most likely find yourself in the following cycle when using Subversion:

The "svn update" commands keep you in sync with other developers, who work on their files in their own working copies of the repository. If you go for long periods before committing changes, it is still good to issue "svn update" commands every once in a while in order to ensure that you don't stray too far from the evolving code base. If you don't commit that frequently, your development process would look like this: