Comparing AccuRev to Subversion

Technical Comparison

OverviewThe AccuRev software configuration management (SCM) system enables and integrates any development methodology (such as Agile, Waterfall, and RUP) with an organization’s existing software assets. Its innovative stream architecture is designed to address the process requirements of today’s complex parallel and globally distributed application development processes, and enables organizations to dynamically manage and adapt their application development processes to their changing business needs. Subversion is an open source tool providing version control for small projects that have limited process needs and lacks the necessary functionality to handle the SCM requirements of larger, distributed teams. This document compares AccuRev and Subversion with respect to several important attributes as presented in the table below. It then summarizes the findings and discusses several key solutions that are enabled with AccuRev, including agile development, continuous integration, globally distributed development, and parallel development.

2

Attribute Subversion AccuRev

Support for complex parallel development processes

Subversion lacks features to support complex parallel development—the limited merge tracking makes merging a burden for developers. Namespace changes such as file moves and renames are not handled appropriately during a merge and frequently cause broken builds.

AccuRev uses streams with built-in inheritance instead of branches. The graphical StreamBrowser gives complete software development process visibility and enforcement. Graphical merging with merge tracking and full namespace support simplifies the merging of changes between code configurations.

Support for distributed development

Subversion has no replication or caching solution to improve performance for geographically distributed teams.

AccuRev’s TCP/IP-based architecture natively supports distributed development over the WAN. For remote teams on a low performance WAN, AccuReplica provides write-thru proxy caching to keep everyone immediately in sync while providing LAN performance for remote, distributed teams.

Developer-centric feature set

Subversion is easy for developers to use but lacks functionality to help teams in a parallel development environment. A full command line interface is provided; third party graphical user interfaces are available but each provides a different subset of functionality.

AccuRev is easy for developers and also provides a comprehensive, cross-platform GUI for all operations A full command line interface is also provided. Features such as built-in private branches, instant overlap notification, and a patch command with patch and merge tracking simplify parallel development.

Integrated change & configuration management

Individual revision numbers are used as change sets in Subversion to provide basic change tracking but do not allow developers to work easily per-change instead of per-file. Tracking a logical change consisting of multiple revisions must be managed outside of subversion.

AccuRev provides a robust, native integration between SCM and issue tracking with built-in change packages. Repeated promotes to a single change package are considered a single change that can be propagated to parallel codelines by drag-n-drop.

Support for Complex Parallel Development Processes

Software development today is more complex than at any time in the past. Projects often involve multiple teams working in parallel on several codelines, often employing different development processes including Agile, Waterfall, and others. To support such projects, AccuRev provides several important features, including:

Graphical Configuration Management with Built-in Merge Tracking•Optimal Process Model Enablement and Enforcement•Stream-based Architecture with Built-in Inheritance•

Each of these feature areas is discussed below and the resulting functionality compared to Subversion.

3

Graphical Configuration Management with Built-in Merge TrackingAccuRev facilitates merge management between code configurations with its graphical Change Palette tool. Users simply select the source and destination configurations and the Change Palette displays all the changes that need to be delivered to the destination. The tool also guides the user through the merge process. When the Change Palette is invoked, AccuRev calculates which files need a merge. Only those files that have changed in both the source and destination stream and have not been previously merged are displayed as overlaps. In the event that there are no overlapping files, no work needs to be done to merge the files and the entire set can be promoted to the destination stream as one atomic operation.

AccuRev’s merge tracking ensures that once changes have been merged from one stream to another, only new changes have to be merged when the Change Palette is run again. The stream-based architecture makes calculating these changes and performing the promote operation very fast. AccuRev also has complete namespace versioning to handle deletes, adds, moves, and renames appropriately as part of the merge process. By simplifying the merging process, the Change Palette benefits organizations that need to adapt to rapidly changing business needs.

With the introduction of basic merge tracking in Subversion 1.5, the ability to track merge history is much improved in Subversion. However, there are several shortcomings. First, understanding how subversion merging works correctly requires every end user to be proficient in the merge internals. The moment a simple merge goes wrong, they will need to understand the internals1. Second, the implementation of merge tracking requires a separate embedded database (SQLLite). Though the database is mostly transparent to the end user, administrators now need to maintain both the code repository and the merge history database. Third, merge information and merge history are human-editable properties, which can result in errors being manually introduced. Additionally, there is no support for full history merge or for tracking merges of files with multiple parents. These limitations are not present in AccuRev, which supports full merge history for all files and directories, regardless of their ancestry. Ultimately, merging in subversion should not be taken lightly2. It is also important to note that Subversion has no analog to the AccuRev Change Palette. The result is that users of Subversion must manually merge injected changes or use a 3rd party merge tool, such as the Eclipse-based merge client from Collabnet3, which limits the user to working exclusively in Eclipse in order to have even minimal graphical merge capabilities.

Aside from merging, parallel development requires full namespace versioning, so that code refactoring preserves the history of any moved files and directories. Subversion does not provide full namespace versioning. The move command is simply a combination of svn copy and svn delete, so when refactored code needs to be merged to another branch, the moved files are treated as separate entities. The net result is that previous history of the moved files is lost, rather than being merged into the target branch. For example, consider a case where a file foo.c is renamed to bar.c in a feature branch. Later, new changes are committed to the trunk, including changes to foo.c. When a merge is performed to merge the trunk changes into the feature branch, a new file foo.c (with the contents from the trunk version being merged) is put into the working copy. The moved file, now called bar.c, does not receive the patch. It is not immediately obvious to developers when they end up in this state, and usually only a broken build detects the poor handling of the renamed files. The Subversion manual recommends that “until Subversion improves, be very careful about merging copies and renames from one branch to another”2, a restriction that AccuRev users do not have to contend with.

Optimal Process Model Enablement and EnforcementAccuRev provides maximum flexibility for engineering teams with complex development processes, embodied in the ability to change dynamically the development process through a drag-and-drop operation within the graphical user interface. This feature is extremely valuable for teams seeking to implement an agile development methodology, in which feature work for multiple releases occurs simultaneously, as shown in the process diagram in Figure 1. A team working on a feature using its own configuration (stream) can retarget the work from current development to the next release by simply

1 http://www.collab.net/community/subversion/articles/merge-info.html

2 http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword

3 See http://desktop-eclipse.open.collab.net/

4

dragging the feature stream to the future development stream. Because AccuRev utilizes TimeSafe technology, in which every operation is stored in an append-only database, all changes to the stream hierarchy are recorded and preserved. This gives development organizations the ability to track accurately how the development process has changed over time.

To perform the same retargeting operation in Subversion, a new branch must be created off the future development branch, and then the feature changes must be merged into that new branch. In addition, the amount of merging required increases significantly if developers utilize private branches (an SCM best practice) as well as feature branches. Although Subversion does record the branch creation as a revision, there is limited visibility and traceability of how a branch changes over time.

AccuRev provides process enforcement through various security features implemented from within the graphical user interface, including:

Stream locks, which give• tight control over where and how changes are committed without the need for scripting or undue administrative overheadAccess control lists (ACL’s) to control read access permissions on a single stream or across an •entire repository

The security functionality in AccuRev is completely customizable--any number of groups can be created with any names, and stream locks and ACL’s can be set for an individual user or an entire group. Since the implemented security is visible in the graphical user interface to all developers, it is easy for each user to understand why he is restricted from performing certain operations. By providing maximum flexibility in its stream hierarchy and security configuration, AccuRev enables development teams to implement and enforce any desired development process.

Subversion provides security enforcement through various mechanisms. Access can be controlled with config files stored in the repository, through operating system permissions using ssh, or through the configuration of an Apache webserver. In all of these cases, preventing read access to files requires configuration to be performed outside of the Subversion tool itself. To prevent users from committing to a branch, a pre-commit hook, or trigger, can be employed. Again, this trigger must be maintained outside of Subversion. With Subversion’s security mechanisms, users have no visibility into the restrictions until they try to perform operations in the restricted area.

Feature XTarget: 3.0

Feature YTarget: 4.0

Feature ZTarget: 3.5

BugFixFeature Z_<date>Target: 3.5

DeliverRe

base

Deliver

/main

Renamed after Re-baseing

Development

Release2.5

2.5.1

2.5. Release Branch

Patch

Figure 1--Sample software development process supported by AccuRev.

5

Stream-based Architecture with Built-In InheritanceAccuRev uses a stream hierarchy to represent an organization’s development hierarchy and process model. Streams are a superset of the functionality provided by branches and labels. In contrast to file-branch-label systems however, streams consist of data that describe a given software configuration, rather than being containers for physical files and directories. Because the data associated with a stream is relatively small, there is no practical limit to the number of streams that can be used to implement a desired software development process, and no concern for bloating the repository. Since each stream has a clear position in the stream hierarchy, the hierarchy can be represented visually. Streams also can be reparented, enabling engineering teams to respond quickly and flexibly to changing workflow and development requirements. As illustrated in Figure 2, the graphical StreamBrowser gives all stakeholders (Technical and Business) a complete graphical view of all aspects of the software development process including snapshots of past releases, streams for active projects, who is working on each project, what changes are being made, and the current state of any given in-progress release.

Figure 2--The AccuRev StreamBrowser provides a complete graphical view of the software development process.

Streams also provide built-in inheritance of code changes. When changes are promoted to a parent stream, they are automatically seen in child streams unless a child stream contains active changes to the same file (in which case the file is flagged as an overlap, indicating that a merge may be required). The StreamBrowser provides a graphical view of the inheritance structure and, therefore of the “rules” for creating code configurations in developer private workspaces. Finally, since the stream hierarchy is automatically versioned in AccuRev, it is straightforward to visualize how the stream hierarchy, and therefore the development process, has evolved over time.

With Subversion, creating branches is very simple. Branches are copies--there is no internal concept of a branch. Subversion does use “cheap copies”, creating a new directory entry pointing to an existing tree instead of duplicating data, which limits the growth of the repository. Branches are typically created in a “branches” subdirectory of the project in the repository and an individual file, subdirectory, or the entire source tree can be copied to a new branch. Subversion does not provide any visibility into the overall branching structure. The repository browser displays the folder structure, but this only shows what branches exist, listing each as a folder in the branches directory, as shown in Figure 3. The revision graph will show the complete branching structure of an individual file or folder, but there is no out-of-the-box mechanism to understand the overall branch structure.

6

Figure 3--Branches in Subversion have no relationships to each other and the TortoiseSVN repo browser displays the branches as a flat list of directories.

The practice of copying a directory structure to create a branch also adds another complication. Since an entire project is typically branched even in cases where only a small subset of files will be changed, and the revision is recorded for each file in the project at the time that the copy command is performed, it is not straightforward to identify which files were actually changed in the copied configuration. The simplest way to see this information is to first identify the revision number of the copy that created the branch (by using the svn log command) and then view the differences between the copy revision number and the current revision number. In AccuRev, this operation is handled automatically via the Default Group indicator in the stream browser, which shows all of the new file versions that have been promoted to the dynamic stream.

Because Subversion is a file-based, branch and label version control system and branching relationships are not tracked, there is no concept of inheritance. Once a directory structure is copied to a new branch, the copy is completely isolated from changes being committed to other branches, requiring the user to merge changes from the other branches into the configuration as needed. Since merging is often problematic in Subversion, this branch-and-merge approach forces serious limitations on parallel development.

Support for Distributed Development

Like Subversion, the AccuRev architecture natively supports distributed development over the WAN. While this works well when there are single users scattered throughout the world or for small remote teams needing only occasional access to the repository, connecting directly to a central repository is not optimal for large distributed development teams. Since users must connect to the central repository even for read operations such as seeing the history of a particular file or of the repository, listing the branches or tags in the repository, and viewing differences between two branches or tags, performing these operations can be bandwidth-limited, and developer performance is hindered by the lack of replicated meta-data. Developers can experience even larger performance decreases over the WAN for write operations--every time a user updates a working copy, checks out from a branch, or exports files to disk for a build, they must wait for the data to be pulled over the WAN.

7

AccuReplica provides replication at remote sites in order to improve performance in development organizations with large remote groups and a sub-optimal network infrastructure. With AccuRev, an AccuReplica server can be used at each distributed location. The meta-data from the main server is synchronized to each replica, providing LAN-speed read access for history and differencing operations, and for viewing the stream hierarchy. In addition, because AccuRev caches file data on the replica, remote teams see LAN-speed performance for data-fetching operations such as updating a workspace and populating files to disk for a build. AccuReplica servers are simple to set up and configure, and end users do not need to learn any extra commands to use a replica server. They simply point their client to the replica server and continue their work. With AccuRev’s replication model, all development teams work as if they are co-located with minimal administrative overhead.

Subversion users who want a replication solution must look to a third party solution such as Mercurial or Wandisco. While these solutions provide some benefit, they represent not only an additional cost, but also add complexity from the technical, administrative, and support perspectives. AccuRev users on the other hand can obtain stream-based replication as a fully supported option, and enjoy the same ease of administration and high-quality technical support as single-site AccuRev installations.

Developer-centric feature set

Although AccuRev provides significant benefits to process-oriented managers, ultimately developers rely on the SCM system for their day-to-day work. AccuRev enables developers to be more productive than with Subversion, due in part to several developer-centric features described and compared with Subversion below.

Consistent Functionality Between User InterfacesAccuRev provides a mature, comprehensive graphical user interface that is the same on all platforms. In addition, since the GUI is a Java application that makes calls to the command line, the functionality of AccuRev is consistent between the two interfaces. The full command line interface is also useful for automating tasks. There are a variety of open source GUI’s that can be used with Subversion, the most popular being TortoiseSVN, a Windows Explorer integration, WebSVN, a web interface for browsing the repository, and RapidSVN, a platform-independent GUI. The functionality varies tremendously between these three interfaces. In addition, since none of them is installed with the Subversion client, the graphical user interfaces are additional software packages that have to be distributed, maintained, and debugged by the IT organization.

Built-in Private Branches With AccuRev, each developer works in his own private workspace. Requiring no external scripting or management, AccuRev workspaces give users private branches with full SCM capabilities, including the ability to checkpoint work without having to share it with the rest of the team. Workspaces also provide a simple means of doing code reviews and approvals. A team member can review the changes in a teammate’s workspace without needing physical access to the workspace, and the team lead can then promote the changes if they are approved. Subversion does not supply private branches out-of-the-box. In order to have a subset of the AccuRev functionality, either each user must manually create their own private branch, or scripts must be written and maintained to automate the creation of private branches for all users.

Automatic Merge-Required NotificationAn AccuRev workspace gives developers writeable files that can be edited directly without a checkout operation. This provides multiple users with concurrent access to a set of files, ideal for complex parallel development processes. Whoever finishes his work first is free to promote it. Any other user working on the same files from a stream in the same sub-hierarchy will see an “overlap” status immediately. The

8

overlap indicates that a newer version is available and that a merge will need to be performed before the user’s private workspace changes can be promoted. With Subversion, although a user must check out a file before he can edit it, multiple users can, by default, check out and work on the same files at the same time. When new file versions are checked in by someone else, though, there is no automatic status notification to the users still working on the same files in their working directories. A user is not notified of any changes to be merged until he performs an “update” command. With this approach, the user has limited visibility into how much work will need to be done in order to merge new changes with his own work in progress before he will be able to commit his work, and can lead to lost time and productivity.

Patch SupportThe “patch” command in AccuRev gives developers an easy mechanism for inserting a specific set of changes into other file versions that require that change. For example, consider the common scenario in which a change from new development needs to be applied to maintenance. In this case, there is a good chance that multiple changes have been made and only a specific change should be applied. With AccuRev, you simply select the version that contains the one change you need and select “patch from” to patch the change into your current version in maintenance. AccuRev records the patch in the element history. Subversion has a patch command but does not track the patch operation, providing zero visibility into what has been patched from one release to another. More importantly, since the patch is not recorded in the file’s version ancestry, the patch information is not used to simplify future merges.

Integrated Change and Configuration Management

AccuRev offers a robust integration between version control and issue tracking, without any required external triggers or scripting. Organizations can use AccuWork, the integrated (i.e. common database) issue tracking tool included in AccuRev, or a third–party issue tracking tool. When a developer promotes files from his private workspace, he is prompted to choose an issue record with which to associate the changes. The composite of all changes associated with the issue through multiple promote operations is contained within a single Change Package. Once this association is made, it is preserved as the changes are merged to other streams in the stream hierarchy. The atomicity of Change Packages is retained, even if multiple sets of changes are delivered together. AccuRev provides several useful operations around Change Packages, including:

Operate at the Change Package level instead of at the file level•View active Change Packages in a stream•Show differences between any two code configurations (streams, workspaces, and snapshots) by •Change Package.Promote a Change Package from one stream to another•Revert a Change Package from a stream.•

Together these provide AccuRev users with a rich set of functionality to manage code configurations and feature- or issue-based development.

Subversion uses revision numbers to track change sets. Since it does not come with its own issue tracking system, a third-party system must be employed in order to tie commit revisions to issues. With most third-party issue tracking integrations, the issue or defect tracking numbers are placed in a comment as part of a commit operation. A trigger then parses the commit comment and writes the revision number and possibly the file versions to a field in the issue record in the third-party system. This is error prone since the user must manually enter the issue number into the comment.

With Subversion, it is difficult to work effectively by change set. This is especially true when a change set is created by multiple commit operations. For example, a user works on a change for issue 1 and commits

9

it to a branch as revision 4. Next, another user commits a completely unrelated change for issue 2 to the same branch, creating revision 5. The first user at some point realizes that some additional changes need to be made for issue 1. He makes that change and commits it to the branch as revision 9. Now, the change set for issue 1 shows revisions 4 and 9--there is no visibility into the composite set of changes for the change set. Working with this change set now requires multiple operations. If, for example, the user wants to merge the changes for this change set into another branch, two different merge operations must be performed--first the user must merge the changes between revision 3 and 4; he must subsequently merge the changes between revision 8 and 9. The upper part of Figure 4 illustrates how this example is handled in Subversion.

As seen in the right hand side of Figure 4, AccuRev treats the set of changes created by both code changes for issue 1 as a single Change Package. Users can easily see the complete set of file versions for Change Package 1 and, if desired, merge the entire set of changes for the fix as one operation.

Finally, with Subversion, the granularity of change sets is lost if a set of changes is merged from one branch to another. This makes it difficult to ascertain exactly where a particular set of changes has been applied. In most cases, users try to merge one change set at a time and enter the issue number again when committing the merged changes. This is both tedious for the user and prone to mistakes. Fundamentally, Subversion lacks any notion of atomic change sets, and therefore promote, revert, diff, and view functionality are difficult at best and in many cases, impossible.

Summary

This paper has focused primarily on a feature comparison of AccuRev and Subversion around process enablement, distributed development, developer-friendliness, and change management. In this summary, we take a broader view and tie these features together to introduce the reader to the solutions that AccuRev enables out-of-the-box. These solutions, described below, would not be feasible with base Subversion, and thus would require expensive scripting and maintenance.

AccuRev Change Packages

Change Package #1

Foo.java version 1Bar.java version 5Test.txt version 2Sample.java version 4ReadMe.txt version 1Test.txt patch

Change Package #2

A.java patchB.java version 8-10C.java version 6D.Java version 12Sample.java version 5Text.text version 7

Issue 1

Issue 2

Revision 4Revision 4

Revision 9Revision 9

Revision 5Revision 5

Revision 10Revision 10

Revision 13Revision 13

Foo.java version 1Bar.java version 5Test.txt version 2

Sample.java version 4Test.txt version 10ReadMe.txt version 1

A.java version 4B.java version 8C.java version 6D.Java version 12

B.java version 10Test.txt version 7

Sample.java version 5A.java version 10

Issue 1

Issue 2

Subversion Change Sets

Figure 4--Subversion treats a single revision as a change set; AccuRev change packages track multiple sets of changes as a single object.

10

Agile DevelopmentMany software development organizations are considering moving to an agile development methodology in order to increase product quality, decrease costs, and respond more quickly to market needs. Since agile processes rely on fast moving requirements, rapid code changes, and shorter development cycles, the demands on SCM and other tools are different from those for traditional methods such as Waterfall. AccuRev enables development teams to implement and manage agile development processes through its flexible process management capabilities, most notably the ability to designs code flow processes directly in the AccuRev tool.

Continuous IntegrationBy extending the idea of a nightly build, where code changes are built and tested nightly, continuous integration helps to reduce integration problems, and to identify and resolve problems more quickly. AccuRev enables continuous integration through the StreamBrowser and the ability to control strictly how code can flow through the development process. Code that passes a continuous integration build and test cycle would be automatically promoted for further testing and release, while code that fails would remain in a lower-level stream to be corrected by developers and retested.

Geographically Distributed DevelopmentAs described earlier, AccuRev provides innovative solutions to assist companies in managing globally distributed development, whether it is between wholly owned locations of one company, or between company sites and independent offshore consulting sites. Several key AccuRev features combine to address the performance, security and other issues that arise when software development spans multiple locations, including the fast native protocol used for all client/server communications, the AccuReplica solution for streamlining distributed development, and the user and stream security mechanisms such as ACLs and stream locks.

Parallel DevelopmentParallel development occurs whenever a software development project requires separate development efforts on related code bases. For example, when a software product is shipped to customers, a product development team may begin working on a new major feature release of the product, while a product maintenance team may work on defect corrections and customer patch releases of the shipped product. AccuRev provides several features to enable parallel development, including the Change Palette for identifying and performing merges, the ability to easily retarget development work from on stream to another, and full support for namespace merge and complex code refactoring. These solutions are developed in detail at www.accurev.com/solutions.html. Each of these solutions has one thing in common – they are all available with no additional cost as part of the AccuRev SCM tool. In contrast, Subversion users are faced with an inflexible file-branch-label system that requires extensive scripting and maintenance in order to obtain even a subset of the default AccuRev functionality. AccuRev is more than the tool swap that users switching to Subversion will obtain – it is a process upgrade for serious professional development teams looking to face and overcome today’s complex development challenges.

©2009. All Rights Reserved.AccuRev and AccuWork are trademarks or registered trademarks of AccuRev Inc. All

other marks are property of their respective owners.

AccuRev, Inc.10 Maguire RoadLexington, MA 02421

Phone: 1-800-383-8170sales@accurev.comwww.accurev.com