Apache Subversion (also referred to as SVN) is an open source version control system. Although it’s widely used for managing source code files, it can actually be used to manage any type of file: images, videos and Word documents can all be managed with Subversion. At its core, Subversion allows teams to manage and coordinate the changes being made to a collection of files.
Subversion consists of two major elements. The first is the repository, which is a server where all your files are stored. The most recent revision of the repository is called the Head, although you can access previous versions from the repository. The second element, is the working copy, which we will explore in-depth in this post.
The Working Copy
‘Working copy’ is a term that’s thrown around a lot in Subversion tutorials and guidelines – but what exactly is the working copy, and how does it work? Essentially, a Subversion working copy is a directory tree on a local system that looks like any other ordinary directory full of files, but it provides a developer with their own private work area, complete with copies of the files contained within the repository. Subversion waits for instructions before making your working copy changes public, or incorporating other people’s changes into your workspace. When you’re ready to perform either of these actions, Subversion has the following commands:
- svn commit – sends changes from your working copy to the repository. Log messages can be added with either the –file or –message switch.
- svn update - updates your working copy with changes from the repository. The –revision switch can be used to provide a revision, or a range of revisions, to be updated to. If no revision is specified, this command brings your working copy into line with the HEAD (i.e the latest) revision.
The working copy contains all the files that have been checked out from the Subversion repository, but it also contains some additional files generated by Subversion to help maintain the working copy. One of these additional files, is a ‘.svn subdirectory’ which serves as the working copy’s administrative directory, and helps Subversion distinguish which of the versioned files contain unpublished changes, and which files are out of sync with the repository.
If you’ve been using previous versions of Subversion, you’ll notice that the .svn subdirectory underwent a major change in Subversion 1.7. In 1.7, the working copy metadata is stored in a single location, with just one .svn directory in the root of the working copy. Previously, Subversion maintained a .svn directory in every versioned directory of the working copy.
Things to Watch out For
The .svn folders are critical to Subversion’s smooth running. Typically, the best cause of action is to leave them alone, but there are several issues worth bearing in mind, to avoid disrupting these hidden folders:
- Do not delete! – the .svn file contains the metadata that links the parent folder with the repository, so if you delete .svn, your working copy will be unable to communicate with the repository – Subversion will stop working completely!
- No nesting – do not try to nest one working copy inside another working copy (regardless of whether the working copies have been checked out from the same repository, or different repositories.) Nesting will confuse the .svn folders, and it is likely they will be unable to communicate with any of the corresponding repositories.
- Watch out for hidden .svn folders – make sure that when you are adding a folder to your working copy, it doesn’t contain a hidden .svn folder. If you try to copy a folder into a working copy that already contains a .svn folder, you will just get an error. If you really need to add the folder, you must first delete all the extra .svn folders.