Technical Comparison

Comparing AccuRev to Subversion

Overview
The 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.
 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 Subversion has no replication AccuRev’s TCP/IP-based

development or caching solution to improve
performance for geographically
distributed teams.
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 Subversion is easy for developers to AccuRev is easy for developers

feature set 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.
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.

2
Graphical Configuration Management with Built-in Merge Tracking
AccuRev 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 Enforcement

AccuRev 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/
3
 Renamed after Re-baseing

Feature X Feature Y Feature Z_<date> Feature Z

BugFix
Target: 3.0 Target: 4.0 Target: 3.5 Target: 3.5

Development

Deliver

Deliver
se
ba
Re
/main

2.5
Release

2.5.1
Patch

2.5. Release Branch

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

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 overhead
• Access 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.

4
Stream-based Architecture with Built-In Inheritance
AccuRev 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.

5
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.

6
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 Interfaces

AccuRev 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 Notification

An 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

7
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 Support
The “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

8
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.

Subversion Change Sets AccuRev Change Packages

Foo.java version 1
Bar.java version 5
Change Package #1
Test.txt version 2
Revision 4 Foo.java version 1
Bar.java version 5
Sample.java version 4 Test.txt version 2
Test.txt version 10 Sample.java version 4
Revision 9
ReadMe.txt version 1 ReadMe.txt version 1
Issue 1 Test.txt patch
Issue 1
A.java version 4
Issue 2
Revision 5
B.java version 8 Issue 2 Change Package #2
C.java version 6
D.Java version 12 A.java patch
B.java version 8-10
Revision 10
C.java version 6
B.java version 10 D.Java version 12
Revision 13 Test.txt version 7 Sample.java version 5
Text.text version 7

Sample.java version 5
A.java version 10

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

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.

9
Agile Development
Many 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 Integration
By 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 Development

As 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 Development
Parallel 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.

AccuRev, Inc. Phone: 1-800-383-8170

10 Maguire Road sales@accurev.com
Lexington, MA 02421 www.accurev.com

©2009. All Rights Reserved.

AccuRev and AccuWork are trademarks or registered trademarks of AccuRev Inc. All
other marks are property of their respective owners.

10