CHAPTER 17 ■ VERSION CONTROL WITH SUBVERSION
Branches are often seen as an advanced Subversion topic, largely because of the difficulty of some of
the concepts involved. For large or long-lived projects, though, branching soon becomes an essential
technique.
Summary
Subversion comprises an enormous number of tools, each with a daunting range of options and
capabilities. I can only hope to provide a brief introduction in the space available. Nonetheless, if you
only use the features I have covered in this chapter, you should see the benefit in your own work,
whether through protection against data loss or improvements in collaborative working.
In this chapter, we took a tour through the basics of Subversion. I looked briefly at configuration
before importing a project. I checked out, committed, and updated code, finally tagging and exporting a
release. I ended the chapter with a brief look at branches, demonstrating their usefulness in maintaining
concurrent development and bug-fix strands in a project.
There is one issue that I have glossed over here to some extent. We established the principle that
developers should check out their own versions of a project. On the whole, though, projects will not run
in place. In order to test their changes, developers need to deploy code locally. Sometimes, this is as
simple as copying over a few directories. More often, though, deployment must address a whole range of
configuration issues. In the next chapter, we will look at some techniques for automating this process.