Comparing concepts between Subversion and Rational Team Concert
Rational Team Concert offers much more powerful source code management than Subversion. This reference walks you through the major differences between the RTC and SVN SCM capabilities, concepts, and commands.
Capabilities
RTC and SVN both offer versioned source control that scales for distributed development teams. However, that is where the similarity ends. There are several things that RTC can do that SVN can’t.
Store code safely on the server without sharing it
In a perfect world, developers would write perfect code the first time. They could literally check-in code as they type it. In this perfect world, developers without this magical ability would still have hard drives that never crashed, meaning they would never lose code that they hadn’t checked in. In this imagined perfect world, SVN is a fine tool of choice. In the real world, we know that code is never perfect the first time, and hard drives do crash. There is always the risk of losing that which you have not checked in. Depending on the complexity of the work effort, days or even weeks of work could be in this source control no man’s land. Sure, you could use branches, but have you ever merged SVN branches? It can be quite difficult!
RTC offers the perfect solution with “repository workspaces”. Instead of checking-in to a shared development line, RTC users check code into their repository workspace, where it is safely backed up on the server (your server administrators run backups, right?) The code is not visible to other team members until you deliver it to an upstream flow target, generally the team’s stream. This is such a great idea that the RTC client has a default option to automatically check-in changes to your repository workspace. The repository workspace feature alone makes RTC worth switching to!
Full traceability out of the box
Subversion may allow you to add external tools for traceability, but in RTC you automatically get full traceability. Source code change sets are easily linked to work items without ever leaving your IDE. Change sets are automatically linked to builds, and work items are automatically linked to builds and plans. This means that anyone, be they developer, tester, project manager, or other role, can open a resource like a build report and see a full list of work items and changes that are in this build. No more guessing “Did the fix to the bug I opened?” or “Did this feature make the build?”. It’s all automatically included by RTC’s traceability. It couldn’t be easier!
Organize code with components
RTC gives you the opportunity to organize your code into logical components. This a great way to separate out concerns, like Build, Core Code, Documentation, Test, and others – just put them in separate components. Developers can load only the components they need to do their jobs. There is no need to juggle multiple repository connections as SVN components might force you to do, just load the components you need from the stream and be on your way.
Do it all from your IDE
With Rational Team Concert, developers never have to leave their IDE. Everything from source code management, to bug tracking, to managing builds and release plans can be done inside an IDE. There is no complicated environment setup, just install the RTC client and away you go!
Concepts (Artifacts)
The key artifact conceptual differences between RTC and SVN are repository workspaces, components, and change sets.
Repository workspaces
In the most basic setup, SVN users will check in from a working copy directly to the trunk of their repository, where RTC users will check in from their sandbox to their repository workspace and then deliver to their team’s stream. This two-phased commit approach with repository workspaces offers many benefits:
- The repository workspace lives on the server for ease-of-backup. (SVN requires you to think of multiple branches here.)
- Running a “deliver” operation in RTC is much easier than merging SVN branches.
- You can point RTC’s build function to your repository workspace for a private integration build.
Figure: Relationship between repository workspace and stream. In RTC, you check-in to a repository workspace, then deliver to a stream. In SVN you check-in to trunk.
Components
If you wanted components in SVN, you had to either create them as top-level repository folders (with separate branch/tags/trunk folders underneath them, and multiple repository URLs for developers), or create them under each branch/tags/trunk folder (now your repository layout does not cleanly map to an Eclipse workspace). In RTC, components are seamless. Users pick which components they want to load in their repository workspace, and never have to worry about committing code to different repository paths.
Change Sets
SVN may allow you to “fake” a change set by running a diff against different repository revisions, but in RTC change sets are real objects. They can be linked to work items and builds. They are easily reversed, suspended, resumed, or discarded. You can even search for a change set, to find the exact change you are looking for.
Cheat sheet
The other key artifact concepts are outlined below:
Subversion | Rational Team Concert | Notes |
|---|---|---|
| Working copy | Sandbox | Local code on your development machine. In RTC a sandbox is in synch with a repository workspace. One and only one sandbox should be connected to a repository workspace. |
| Branch/Trunk | Stream | A single line of development. In SVN these are just copies with no semantics attached. RTC has numerous capabilities around streams including the ability to automatically promote changes from maintenance streams to development streams. |
| Component | A component is a logical grouping and container of various source artifacts. Typically the files for a stream are separated into multiple components. | |
| Repository workspace | In their simplest form, they are a server-side backup of your sandbox (working copy). They can also be considered personal branches that easily merge back to the stream. | |
| Tag | Baselines/snapshots | Snapshot of some state. In SVN these are just copies. An RTC snapshot (stream-level) is a collection of component baselines. |
| Revision | Change Set | If you check-in multiple SVN files at once, they are only related by a common revision number and commit log entry. In RTC, there is metadata called a Change Set that groups files that were committed at the same time. Using an svn diff command against revision n (svn diff -r(n-1):n) you can implicitly generate a change set. |
Concepts (Commands)
RTC offers all of the capabilities of SVN and more. SVN commands have clear corollaries in RTC, as shown in the cheat sheet below. The most significant difference is the two-step commit in RTC, which as we’ve discussed earlier is a fantastic feature. RTC offers two major modes of operation: command line or Eclipse client. The command line interface is comparable to the SVN command line. The Eclipse interface to RTC offers features and benefits beyond command line or SVN-based extensions. In particular, the “Pending Changes” view in the RTC rich client is a great tool that manages most source control interactions.
The RTC command line interface is summarized here: http://publib.boulder.ibm.com/infocenter/rtc/v2r0m0/topic/com.ibm.team.scm.doc/topics/c_scm_cli.html
The RTC Eclipse interface is summarized here: http://publib.boulder.ibm.com/infocenter/rtc/v2r0m0/topic/com.ibm.team.scm.doc/topics/c_scm_eclipse.html
Cheat sheet
The key command concepts are noted below:
Subversion | Rational Team Concert | Notes |
|---|---|---|
| Check-in | Check-in and Deliver | SVN has a one-step code commit process that goes directly from working copy to repository. RTC has a two-step process: first check-in to your repository workspace, then deliver to your flow target (usually a stream). A two phased approach could be mimicked in SVN by checking-in to a personal branch and later merging that branch to trunk. |
| Blame/Praise/Annotate/Log | Annotate/Show History | Show change history summary |
| Check-out | Load | Create a new local working copy |
| Update | Accept | Download remote changes. Both will prompt to merge in case of conflict. |
| Merge (between branches) | Deliver to a flow target | RTC’s flow targets make merging seamless using common Accept and Deliver operations. |
| Property commands (ex: propget) | Properties | Work with property metadata on a file. |
| Lock/Unlock | Lock/Unlock | File-level locking is supported |
| Revert | Discard | Undo local edits |
| Status | Status | Determine differences between your working copy and the repository. The Eclipse client for RTC shines here with the Pending Changes view. |
| Switch | Change your flow target | Refresh working copy from a different source and deliver changes to that new source. |
| Create Tag | Create Snapshot | Mark a snapshot of the state of your code. In SVN, this is accomplished via a copy operation off of the trunk. In RTC, this is done by taking a snapshot at the stream, which creates baselines for every component in the stream. |
| Create Branch | Create Workspace/Stream | Create a new line of development. Both systems allow you to merge from these lines back into your trunk, but RTC manages the stream relationships to make merging seamless. |
| Suspend | You can take a set of changes and suspend them, which backs them out of your sandbox but remembers them for when you want to start them up again. This is much easier than creating additional SVN branches or working copies. | |
| Resume | Continue working on a suspended change set by restoring it to your sandbox. | |
| Reverse | Take a committed change set and create a new change set that undoes the first set. | |
| Associate work item | Provides full traceability between work items and change sets. | |
| Create change set | You can explicitly control the groupings between files you are checking in at the same time. This is great when you have multiple unrelated changes in your workspace at the same time. | |
| Add/remove components to workspace | You can divide your repository into logical groups called components. Then, developers do not need to load all components into their workspace, but rather only the components they need. |
For more information
- Easing into Jazz Source Control
- Jazz Source Control: Design Objectives
- Multiple Stream Development
- Stream strategies with Rational Team Concert 3.0
About the author
Andrew R. Freed has been with IBM since 2003. He has worked on e-commerce and retail solutions as well as virtualization technology. Currently Andrew is prominently involved in a migration of hundreds of Subversion-based projects to Rational Team Concert. He has used Rational Team Concert since version 1.0 and believes in the SCM architecture it provides. Andrew can be contacted at afreed@us.ibm.com.
Copyright © 2011 IBM Corporation