accurev subversion analysis
Post on 28-Nov-2014
Embed Size (px)
Comparing AccuRev to SubversionOverview The AccuRev software configuration management (SCM) system enables and integrates any development methodology (such as Agile, Waterfall, and RUP) with an organizations existing software assets. Its innovative stream architecture is designed to address the process requirements of todays 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.
AttributeSupport for complex parallel development processes
SubversionSubversion lacks features to support complex parallel developmentthe 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.
AccuRevAccuRev uses streams with builtin 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. AccuRevs 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. 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. 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 distributed development
Subversion has no replication or caching solution to improve performance for geographically 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.
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.
Support for Complex Parallel Development ProcessesSoftware 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.
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. AccuRevs 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 another2, 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 simply1 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/
Renamed after Re-baseing
Feature X Target: 3.0
Feature Y Target: 4.0
Feature Z_ Target: 3.5
Feature Z Target: 3.5
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