Using version control with Subversion enables you to manage all the changes in your files, compare different revisions, revert to previous versions, and safely collaborate with other users working on the same set of files. This post aims to provide some tips for doing version control with Subversion that will help you become a pro Subversion user.
Subversion does not impose any restrictions on how you organize your files and directories. However, best practice recommends that you structure your repository properly before you start committing files into it. There are many ways to structure the repository. The Apache Subversion developers recommend the use of a “project root” which contains three subdirectories: /trunk, /branches, and /tags. A repository may have one or more project roots.
The trunk is where you store your latest versions of the files and directories. It is a good idea not to flood the trunk with commits of incomplete changes. Instead, you can do significant changes and modifications to your files using branches, without disrupting the newest version of the file. Then you can use tags to mark “code milestones”, which provide a snapshot of the files at a certain point in time at a known state (e.g. release X).
In software development, new features are often introduced concurrently. One recommended practice is to create a branch where you will save files while developing the new feature. This is important because when bugs arise during your development, you won’t disrupt the work that is currently in progress in the trunk. Also, you are able to revert to a previous revision on the branch without affecting the trunk. When you are finished coding the new feature and testing it, then you can merge the code in the branch onto the trunk. The trunk will then have the merged latest version of the files. At this point the branch can be safely deleted.
When you make modifications to your files, it is an important practice to always write descriptive commit log messages citing why the modification is applied. This is especially necessary in collaborative work. When your team reviews the files, they can automatically see why certain changes are applied to those files. Also, in case a bug must be fixed, developers must check the modifications that could have caused the bug to arise. The short explanation of modifications could help find the possible cause of the bug and suggest necessary changes.
Subversion does not need to assume that every file must be version controlled. Some outputs like pdf or postscript files, which are generated by converting documents, need not to be placed in version control.
In Subversion, each directory can have a svn:ignore property assigned. This property consists of a list of file patterns that the Subversion operations will ignore. When set, the svn:ignore property can filter unversioned files when you use the commands: svn status, svn add, and svn import.
You can set a svn:ignore property on a directory by running the command:
svn propset svn:ignore <pattern> <directory>
Where <pattern> is a list of files or wildcard patterns to match files that should be ignored (e.g. “*.tmp”) Note: This can also be done using the global-ignores run-time configuration option, which is stored in the global Subversion config file. It is not generally recommended to ignore files this way however, as this configuration setting affects ALL repositories, and is not shared with other users.
A tag is commonly used in version control to describe a snapshot of the project a certain known point in time. Although every commit in Subversion results in a new repository revision that is a snapshot of the file system after each commit, a tag is intended to record a specific revision that represents a known configuration, such as a product release or development milestone.
In Subversion there is no distinction between branches and tags. In fact, they are created the same way. The only difference is where they are located in the repository. This is why it is a good idea to have a defined repository structure from the outset (see point 1 above).
Generally, once created a tag and should never be modified, although SVN does not enforce this. Never commit to a tag, instead create a new branch if you want to make changes to a tagged version.
Adopting some or all of these five pro tips for version control with Subversion in your daily workflow will help you become a more efficient and effective Subversion user.