Subversion and Rational Team Concert Feature Comparison

Note: I need to recognize and thank Khurram Nizami, Rolf Nelson, and Hugh Cushing for helping me pull all of this information together.

This is a brief document which outlines the high level functionality that is lost when using a Subversion bridge for SCM capability in a Jazz based environment, instead of using the Rational Team Concert based SCM.  It is understood that in some cases it will be preferable to use Subversion for SCM capabilities in some Jazz based scenarios.  I only see this as a viable alternative in the following situations:

• Small development teams, in a single location, where the expense of RTC licenses outweighs the benefits of fully integrated tools.
• Teams currently using Subversion for SCM, where the pace of change being propagated across the organization needs to be controlled.  Some teams will want to stay with Subversion during early phases of migration due to schedule risks, training logistics, release schedules, or immature internal support structures.

Functionality that remains unchanged in an RTC/Jazz based environment, where Subversion is used for SCM functionality:

• All of the Agile and Iteration planning capabilities remain, since these are not associated with the SCM piece of RTC.
• All of the work item capabilities for state, content, and linking of data remain, as work item functionality is not directly impacted by a change in SCM capability.
• All of the collaborative functionality (instant messaging, discussions, RSS notification, email notification, etc.) capabilities remain intact, as these are not directly impacted by a change in SCM capability.

Functionality and capability that you lose with Subversion plugged into RTC (as opposed to Jazz SCM):

• More difficult to maintain, since an additional eclipse plugin (Subclipse ) needs to be maintained, and a separate repository (SVN) also needs to be maintained.
• Build capabilities are impacted, since the build engine must be configured differently for Subversion based SCM capabilities, and because change sets included in a build are not automatically collected.
• The ability to recreate a workspace from a failed build (since Jazz SCM captures a snapshot of the build source before the build is done).  The Jazz build process cannot automatically create a snapshot (equivalent to an SVN tag) when a build is completed; you would have to script the build process to create SVN tags at the appropriate point or have your users do it manually.
• You must manually associate revisions with work items.  This is error-prone when compared to Jazz SCM which automatically does this.
• It’s more difficult to keep changes from a work item separate from each other; i.e. branches and merges are not work-item aware.  You have to remember to create a new branch if you want to keep work items isolated from each other, and you have to remember to revert to the trunk if you want to stop working on a work item.  If you don’t, revisions will get mixed up, and it will be a painful manual process to extract them.  By contrast, Jazz SCM is always aware of which revisions went with which work items; thus it can automate complex operations (for example, its automated “Discard”, “Revert” and “Suspend” operations).  Many Agile based teams demand this capability to put changes “on the shelf” (suspend) when stakeholders change the priority of their user stories.  They then need to be able to take them back “off of the shelf” (resume), when the original work becomes the highest priority again.
• The ability to have server based workspaces.  With Subversion, as soon as you commit, your changes are visible to everyone.  If you don’t want this, you have to branch and merge yourself.  In Jazz SCM, by contrast, checking in a version automatically records the changes on the server, but doesn’t make them visible to others until you do a Deliver.  This makes Jazz SCM somewhat safer, because people are more likely to save their work to the repository if doing so doesn’t simultaneously publish the changes to the entire team.
• There is no process enablement for SCM operations, since with Subversion these SCM operations are external to Jazz.  With Jazz SCM you could require that a static analysis on your code be performed before you did a deliver of code fixes to your teammates, but you cannot do that through RTC’s process framework in Jazz.  This would require the integration (and maintenance) of other open source (or commercial) build automation tools.
• You lose the Jazz SCM concept of a component, which gives you the ability to compartmentalize your artifacts into a “producer/consumer” model.  If a team should be able to change front-end Java code but only read EJBs, this is easily modeled and enforced in Jazz SCM, but has to be done manually in Subversion (e.g. by editing the svnserve.conf files to support path-based access).  Even if manually done in SVN, you still lose a very powerful level of abstraction, which makes it easier to track the relation of components to each other via baselines and snapshots.
• Without the concept of a component, it is more difficult to determine the scope of changes that have impacted the code.  With Jazz based SCM, two baselines of a particular component can be compared, and the differences can be viewed at a change set, work item, or individual file level.  With Subversion, you just have a bunch of changed files.
• The lack of an easily implemented (and visualized) stream model for the support of parallel development activities, the segregation of changes, and the promotion of code to various stages of test and validation.

Functionality and capability that you lose with Jazz SCM instead of Subversion:

• RTC can’t use the new changelist feature of SVN to keep changes segregated, because changelists are too limited (e.g. changelists can’t include directory tree changes).  RTC does provide a more powerful capability to do this through the tracking of change sets, or the creation of alternative workspaces or streams.

It is important to remember that while the negatives of remaining with a Subversion SCM component within the Jazz framework seem to greatly outweigh the positives, there is no one correct answer for all teams and organizations.  There may be sound reasons (financial or organizational) for wanting to use Subversion instead of the Jazz SCM (Rational Team Concert) component.

What is important is that these reasons be clearly articulated, and that the financial and strategic implications of all of the positives and negatives be properly analyzed.  It is only when these impacts are analyzed and the emotion is removed from the equation, that the alternatives can be assessed based on the quantitative impact to the organization, and the business as a whole.  After all, the real reason that you decided to implement Jazz in the first place was to provide value to your business, and to save money.