I actually have an awful lot of time for Rational Team Concert. The VCS is quite well tuned to include some of the notable benefits of DVCSs, while keeping things a bit simpler to work with. Work items are really nicely integrated too.
Clearcase was a good idea in 2001, when the alternative was CVS. In 2015, I am wholeheartedly unconvinced it offers anything over git. (And I'm not a devoted booster of git.)
(I was nominally responsible for a Clearcase setup at Ericsson in 2001. I mentioned it in passing on the 2002 version of my CV, and no later version. I still get pings from those last few Clearcase shops, desperate to find someone willing to touch the thing.)
You may disagree, and perhaps Clearcase has substantially changed its model since then. What in detail do you like about Clearcase over (say) git?
Ah, I have no experience at all with ClearCase - I believe the VCS for RTC is a newer product with some conceptual overlap, but I'm given to understand it is typically substantially quicker and easier to get up and running with.
I'm conflicted on the VCS. It seems powerful, but the "bag of changesets" (instead of linear chain of changesets) model gives me issues when performing operations that I would commonly do on my git repos. In scripts I have written, I've encountered two changesets on the same stream occurring on the same second and accepted them individually in an incorrect order, which put the workspace in a screwy state.
(Also hitting the server for every little operation kills me. Even the command line tool just communicates to a java daemon to go hit the server, arrrrrgh.)
On reflection, I suspect a lot of it is less the actual VCS itself, and more the way it gets exposed in the UI. In contrast to git (where I'm 100% command line), I spend most of my time with RTC using the GUI, which is reasonably well directed towards the most common needs.
I think I also have a lot of positive thoughts about RTC because I remember how easy it felt to get started with it. With git it took me a little while to internalise how it worked, and I screwed up my repositories beyond my newbish ability to recover a few times. When comparing each to SVN, RTC provided me the improvements I cared about most (easy sharing, interim 'commits' prior to pushing to mainline), with very little learning overhead.
Combine that with really excellent work item/defect integration and I think it's a pretty compelling product. As you say, the constant communication with the server is a definite bummer. I think that comes out of the more corporate focus of an IBM product - for a centralised team sitting in the same building as the campus, a bit of server communication isn't such a big deal.
I'd be pretty salty about having to use the VCS if it wasn't so well integrated with the work items. Definite improvement over GitHub in that regard. (I've still entertained the thought of writing some sort of git translation layer, but I don't know either well enough to translate some of the crazier edge cases.)
It is an interesting point, but it really shouldn't matter what order you accept the change sets in as long as you accept them all, correct? Was it something specific to your project that caused there to be issues?
I'll try and reproduce the issue, but I think somehow the workspace knew it was in an inconsistent state, but wouldn't provide me the information to not put it in that state in the first place.
This was "fixed" in later versions of RTC with --accept-missing-changesets [0]
