Subversion Improvements

Enhancing Apache Subversion's merge functionality has been a goal of the project as far back as Subversion 1.4. Major improvements were delivered with Subversion 1.5 and additional enhancements came with Subversion 1.6. Even with those efforts, there are still use cases related to merge operations that can and should be enhanced as the project continues to evolve.

The requirements for merging have been well documented within the Apache Subversion Project and were first published prior to Subversion 1.4. Here at WANdisco, we believe that there are still some vital use cases that are captured in this documentation but are not yet implemented. We are going to focus our attention and dedicate our resources towards implementing some of the remaining higher priority requirements. These include:

Renames have been identified and are well documented in the Merge Tracking Requirements already. True support for merges across renames requires true rename support. This issue has been well documented and discussed for quite some time.

Below is a simple example use case demonstrating the desired effect of having changes automatically merged across a renamed file:

When true rename support is completed, there is still the question of historical data that is currently sitting in literally millions of Subversion repositories world-wide today. Merging across older branches may still require an initial identification linking the "old" file to the "renamed" file. The proposed solution for this use case would be:

  1. Given a tree conflict on a node, "foo", the user has to resolve the tree conflict by informing Subversion that "foo" has been renamed "bar" and then let Subversion calculate the delta between "foo" and "bar"
  2. Record the rename at the same time so that any subsequent merges can utilize this data to handle the rename automatically.

Additionally, there are other areas of improvement that WANdisco will target:

Many Subversion deployments are storing, tracking and updating 3rd party source code. A common use case is the need to initially import and then periodically track and update source code provided to your organization from some 3rd party (a partner, vendor, or an open source project).

While the initial "svn import" works well importing a source tree, subsequent imports should:

These changes should be identified by the import and committed as a single change set into the repository. The change set should represent only those files that have been changed, added or deleted from the new import versus the previous import.