In a programmer’s mind

Not everyone likes what IBM is doing by Looking Glass

I have started using Rational Team Concert (RTC), version 1 and 2, at work for my latest project. RTC is an IBM product based on the Jazz Foundation platform which integrates work item tracking, builds, source control, and agile planning. It tries to manage most of what a software development team will need to do with the same tool.

In that sense, it is similar to Team Server Foundation by Microsoft. You might remember my rant about it.

RTC is geared towards big enterprises. The initial cost for the standard edition is probably enough to justify not to use it for most small and medium teams or companies.

Like many IBM products, RTC tries to do everything from defect management, automated builds, planning to source code management. I must admit that overall, it does manage this feat to a good level.

Without any other delays, here is what I dislike about RTC.

It sends whole files on the wire instead of deltas

Imagine you have a 100 Megs file that needs to be modified and sent back in your central repository multiple times in a day. Let’s also pretend that you are simply changing 10 characters in that file each time. With RTC, whenever you send those changes are sent back in your central repository, the whole file will need to be transmitted on the network instead of the 10 characters.

This is simply unacceptable. It is a waste of network resources and a waste of my time because I need to wait for this transfer to complete. It seems like some operation depends on other ones and you cannot perform them in parallel. Whenever I tried to do too many long operations at the same time with RTC, it shows a model progress windows that completely disabled my ability to use my IDE.

A simple diff algorithm on the client side or on both side would use a few of my heavily underused CPU cycles and it would be way more efficient. This is one of the base concept of most version control system out there. Subversion has been doing this for years now.

It is centrally based

It seems like most people have not discovered the joys of distributed version control yet. During the course of my normal usage of RTC, I have had network failures and disconnects with the RTC server. As soon as I was disconnected, I was left in the cold dark state of anger because I could not do much about managing my source code. For that reason alone, it should be distributed.

It is treating me as an idiot who do not know what he is doing

Whenever I try to do something that might have some repercussions, it shows me a popup asking me if I am sure I want to do that. Here is a typical scenario:

1. I check-in some files while keeping some files unresolved (not checked in).
2. I associate a work item with the new changeset because it is a precondition to delivering a changeset on the project.
3. I try to deliver the changeset.
4. I get a popup asking me if I am sure I want to deliver those files without including the other files that are unresolved.
5. I confirm this action by clicking on yes.
6. There are errors in my project that triggers a precondition failure that makes me unable to complete the delivery.
7. I override that precondition so I can complete my delivery.
8. I click on the “Retry” button so my delivery can be retried with the precondition overridden.
9. I get another popup asking me if I am sure I want to deliver those files without including the other files that are unresolved.
10. I confirm this action by clicking on yes.

Those popups are everywhere within RTC. Many of them are modal ones too. I am not an idiot. I know what I am doing. Stop bugging me and provide facilities to revert my mistakes.

You cannot easily name a revision in the past

There are two named revision concepts in RTC: snapshot and baseline. In short, a baseline is for a component (a kind of project division) and a snapshot is a group of baselines. The problem is that you cannot create them for revision in the past. You can only create them for your current workspace. If you forgot to create a snapshot for your latest deployment, it is just too bad for you. If you really want to create it, you will need to update each file to the state where it was when you did your deployment and create a snapshot with the files in your current workspace. The ugly side of this is that you cannot update your workspace to look like a revision in the past easily either.

Read-only file updates make your project out of sync

For our project, we had some files that were read-only but needed to be updated once in a while. Every time we had to update those files and they were accepted on the developer’s PC, it would put the projects in the related baseline out of sync. It is a state where you cannot do any operations with RTC without having multiple popups telling you that you need to resync your projects. The read-only file updates is only one way to get your projects out of sync. We manage to reach that state in different scenarios.

In other to correct that problem, we had make the files writable and perform the resync operation. This was a real pain.

Considering the whole thing, RTC is not such a bad product. It just has many quicks that are unpleasant and difficult to bear with. If you have the money and want an enterprise product, go for it. If you do not, there are multiple free solutions out there that can do most of what RTC is doing and that can do it better.