Section 2.2. Limitations of Subversion

2.2. Limitations of Subversion

Subversion is a powerful version control system, but it does have its limitations and is missing some features found in other popular version control systems. You can compensate for some of these limitations with external tools that can work with Subversion, and implementations of some of the other shortcomings are planned for future versions of SVN. It is also possible to work around some of SVN's limitations with clever uses of hooks and properties. In fact, workarounds for many of Subversion's limitations are discussed throughout this book.

The following features are some that are either missing from Subversion, or severely limited in their implementation.

Locking

Subversion currently has no support for file locking,^[1] to prevent more than one person from working on a particular file at a given point in time. In most cases, locking isn't the desired behavior anyway, so this is not a major missing feature. It can become a problem, though, when dealing with binary files that are not easily merged. Locking can be partially implemented through properties and hooks, but the result is somewhat fragile. According to the Subversion developers, however, locking is on the list of features to be implemented in the next few releases of the system.

^[1] Locking support is planned for version 1.2 of Subversion, however.

Distributed Repository

Some version control systems (such as the open source Arch system) have support for distributed repositories, which can be extremely important for some larger projects, especially open source projects. Subversion does not currently have any support for distributed repositories, but there is a secondary project, called SVK, that does provide a distributed wrapper for a Subversion repository. There are also some ways to do hot backups of a repository to provide some of the redundancy afforded a distributed system, as is discussed in Chapter 10, "Administrating the Repository."

Visualization Tools

In terms of ease of use and comprehensibility, Subversion's copy paradigm is far above the branching and tagging functionality built into CVS. In its current implementation, though, the copy paradigm makes tracking the path a file takes, as it branches and merges over time, difficult at best. In fact, Subversion puts the task of tracking file history trees on the shoulders of the user. In order to maintain information that should be available automatically, the Subversion user must manually track using information entered into the logs at commit time.

For example, look at the complex repository tree in Figure 2.1. The svn log command would make it easy for me to see all of the changes that were made to the third revision on the main trunk of the repository, but if I want to see that two of the changes occurred on the main trunk and two occurred on branch 2, it would be impossible, unless I had the foresight to keep careful notes in the log entries about which branch a change occurred on.

Figure 2.1. Subversion fails to provide the capability to visualize a complex branching tree like this.

Merging History

Merging of changes in Subversion works much the same as in CVS. A user makes changes, and then prior to committing those changes, uses Subversion to merge changes committed by any other developers. Subversion, like CVS, uses a bit of logic to merge together trivial changes and those that don't overlap, while punting anything more complicated to the developer. In this sense, it is equally as good as CVS, which in most cases is good enough. In fact, by giving the developer more information when it does punt on a merge, SVN is better than CVS.

Where Subversion falls short is in another case where merging occurs: merging between branches. When Subversion merges between two branches, it merges all of the differences between the first location and the second location into a third location in the working copy of the repository. This means that if a developer wants to merge changes made on a branch back into the main trunk (or to another branch), the developer needs to specify the differences in revisions on the branch, where the changes to be merged occurred. Unfortunately, this means that the user must keep the accounting information describing when the branch was created (and when it was last merged) in order to ensure that the correct data is merged. Failure to keep track can result in undesired behavior. For instance, you can end up "undoing" a change, if you accidentally remerge a section of a file that has been removed since the first merge. Duplicate merging can also result in spurious conflicts if remerged sections have been modified instead of removed.