Accurev Subversion Analysis

Download Accurev Subversion Analysis

Post on 28-Nov-2014

191 views

Category:

Documents

2 download

Embed Size (px)

TRANSCRIPT

<p>Technical Comparison</p> <p>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.</p> <p>AttributeSupport for complex parallel development processes</p> <p>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.</p> <p>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.</p> <p>Support for distributed development</p> <p>Subversion has no replication or caching solution to improve performance for geographically distributed teams.</p> <p>Developer-centric feature set</p> <p>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.</p> <p>Integrated change &amp; configuration management</p> <p>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.</p> <p>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</p> <p>Each of these feature areas is discussed below and the resulting functionality compared to Subversion.</p> <p>2</p> <p>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/</p> <p>3</p> <p>Renamed after Re-baseing</p> <p>Feature X Target: 3.0</p> <p>Feature Y Target: 4.0</p> <p>Feature Z_ Target: 3.5</p> <p>BugFix</p> <p>Feature Z Target: 3.5</p> <p>Development</p> <p>/main</p> <p>Release</p> <p>2.5</p> <p>Patch</p> <p>2.5.1</p> <p>2.5. Release Branch</p> <p>Figure 1--Sample software development process supported by AccuRev.</p> <p>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 (ACLs) to control read access permissions on a single stream or across an entire repository</p> <p>The security functionality in AccuRev is completely customizable--any number of groups can be created with any names, and stream locks and ACLs 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 Subversions security mechanisms, users have no visibility into the restrictions until they try to perform operations in the restricted area.</p> <p>4</p> <p>Re</p> <p>Deliver</p> <p>Deliver</p> <p>ba</p> <p>se</p> <p>Stream-based Architecture with Built-In Inheritance AccuRev uses a stream hierarchy to represent an organizations development hierarchy and process model. Streams are a superset of the functionality provided by branches and labels. In contrast to filebranch-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.</p> <p>Figure 2--The AccuRev StreamBrowser provides a complete graphical view of the software development process.</p> <p>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.</p> <p>5</p> <p>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.</p> <p>The practice of copying a directory structure to create a branch also adds another complication. Since an entire project is typicall...</p>