It's all about the answers!

Ask a question

[closed] GIT or RTC source control?

Leonardo Marzo (24964852) | asked Feb 04 '13, 1:18 p.m.
closed Sep 21 '23, 6:56 a.m. by David Honey (1.8k17)

We have a large SVN repository, and we're planing to migrate it to either, GIT or RTC SCM. Do you know if there is some comparative analysis done? I would like to know which are the differences between both tools. The cost is not important, I just want to see something like a comparative chart between the features of both, GIT and RTC. 

We´re currently using RTC for planning, and RQM as testing management tool, so the integration with this tools is a important point to take into account. 

I will really appreciate your help. 


Ralph Schoon commented Sep 21 '23, 3:49 a.m.

 I considered this as one of the typical old (from 2013) questions that get answered with questions years after they were asked and closed it. I reconsidered it. This is probably a question that does not age. I will however accept the answer.

Ralph Schoon commented Sep 21 '23, 6:59 a.m.

David and I seem to disagree here 8) 

The question has been closed for the following reason: "The question is answered, right answer was accepted" by davidhoney Sep 21 '23, 6:56 a.m.

Accepted answer

permanent link
Millard Ellingsworth (2.5k12431) | answered Feb 04 '13, 8:00 p.m.
I searched a bit on your behalf and could not find anything that is both current and relevant as a general comparison. Given how well integrated RTC SCM is with the rest of the CLM suite, including the build capabilities and build reporting and the fact that you are already using RTC and RQM, I have a hard time imagining what would make Git a better choice for your team(s). Some items you may find helpful:

A slightly older discussion at StackOverflow:
Martin Nally, Rational's CTO, recently blogged about difficulties they had using git (though if you are not using eGit you may have better results than he reports)

Reading through some of these, it's hard to imagine choosing Git over RTC SCM when you are free to make any choice you want and are already an RTC/RQM user.

Ralph Schoon selected this answer as the correct answer

Leonardo Marzo commented Feb 05 '13, 8:26 p.m.

 Thanks for your answer Millard!

Guido Schneider commented Feb 06 '13, 3:58 a.m.

I think the most important question is "Integration" vs. "Functionality and Performance".

We had in the past the concept of a toolchain with "Best In Class". Today, thanks CLM we are complettly switching to the "Full Integrated" Tool Chain because we worked to much on copies of copies because of synchronisations instead of linkeages and we spend to much time in tool connectors maintenance.

End user may save time in a individual tool which has some big advantages in one function. But all this saving is more than lost in other areas or by other team members, roles. 

Millard Ellingsworth commented Feb 06 '13, 12:12 p.m.

@schneidg I made exactly this same point (about how local optimization of point tools was uninteresting in the larger scope of the project) with someone that pinged me via email. Even before I worked for Rational my evaluation of various tools pointed to RTC as the best overall experience for the team.

10 other answers

permanent link
Jim Ruehlin (79114) | answered Feb 04 '13, 8:34 p.m.
Here's a short article I wrote that has some high-level comparisons between Git and RTC. It includes a couple of links to other articles about Git that you might find useful as well.

The integration between RTC and other parts of the development environment are a big plus. I also think RTC is much easier to use in a day-to-day scenario, while Git is more focused on making life easier for the admin. The to SCM systems have different vocabularies, but similar SCM models in my opinion.

Leonardo Marzo commented Feb 05 '13, 8:25 p.m.

Thank you Jim, that article was interesting 

permanent link
Jirong Hu (1.5k9292258) | answered Feb 24 '14, 9:25 p.m.
I've worked in Canada as a SCM consultant for more than 10 years. In the past, most of time I partnered with Rational to deploy their tools to the large organizations. 2 out of 3 telcos here are using ClearCase/ClearQuest and other Rational tools, 3 out of 5 banks, and a lot of government. I can safely say that in the past IBM tools dominated the market in the large company sector, absolutely no competitors. Life was good, as a Rational tools consultant.

However, it's all over now. Things start to change in the last couple of years, even with IBM's latest effort in RTC. For these companies I mentioned, none of them are moving into RTC after evaluating for years. Overall very few RTC implementations happened here. Why? Three main reasons I can see:
1. Open source tools are a lot better now, even better than Rational tools. GIT/SVN can be a good replacement for version control, JIRA is even better than ClearQuest, TeamCity/Jenkins not worse than BuildForge, Rational has no answer to the binary repository like Artifactory. Is there a Wiki like Confluence? And there are so many plugins available can be easily integrated into these tools too. 
2. License cost, when open source tools are this good and 10 times cheaper, it's very difficult for a SCM manager to propose IBM tools to the management.
3. Development philosophy has changed. Management view of IT has changed. IT budget has changed. The world has changed.

I am deploying GIT, JIRA, TeamCity and Artifactory in one of the bank now, to replace all existing IBM tools.


permanent link
Stuart (61132) | answered Jul 02 '13, 10:42 a.m.
Many of the teams I'm working on have started to move to git. The main reason is that we found scm (Jazz's CLI) to be very hard to use. We really tried to integrate it into our scripted builds but there were just too many problems that we finally gave up. It's a pity because Jazz's overall tight integration between SCM, issue and bug tracking and managing the command development workflows are indeed very impressive. But for the command line junkies in our group, scm was a show stopper.

Geoffrey Clemm commented Jul 02 '13, 11:05 a.m.

Do you remember what the problems were? 

sam detweiler commented Jul 02 '13, 1:08 p.m. | edited Jul 02 '13, 4:23 p.m.

prior to RTC V4, the SCM CLI was not up par with other SCM tools.  so it was near impossible to do some of the actions teams had already used in other integrations.

Stuart commented Jul 02 '13, 1:49 p.m.

Many issues discussed here.

Geoffrey Clemm commented Jul 02 '13, 4:50 p.m.

If there are any post-V4 gaps in the RTC SCM API, please do raise a question about them in the forum, since there might be a workaround (in particular, some of the problems in the RTC SCM API were documentation bugs).

Sreerupa Sen commented Nov 12 '13, 3:55 a.m. | edited Nov 12 '13, 3:56 a.m.

 The command line has actually undergone a huge UX boost  this year, as well as a performance boost.  We spent a lot of time making it more usable from scripts, generating consumable output in JSON/XML, having a much more predictable syntax, being faster and so on. If you're interested, please have a look at the Plan Items that we've done this year and the last year or are doing this year.

showing 5 of 6 show 1 more comments

permanent link
Jens Melgaard (4614) | answered Nov 06 '13, 4:34 a.m.
 After 3 years or so with RTC, I can't vouch for it in any way...

It is not just the command line that is flawed as @stuart points out, there are allot of aspects in RTC that is implemented poorly, the tight integration may impress some (not me), but what does it matter when all the interfaces on top of it is poorly designed and becomes a pain to use.

There are much worse contenders out there, but there are also tools that is far greater IMO...
RTC Tasks and Planning: I would take Jira/YouTrack/Mingle...
RTC Source Control: I would take TFS, SVN, GIT, Mercurial etc...
RTC Builds: I would look at TeamCity, Go, Bamboo...

RTC keeps pointing it's "integration" out as the best thing ever, but there are so many 3rd party options for the other SCM's that integrates flawlessly so it is an academic exercise at best to pull that argument...

At the end, ones a SCM starts overwriting my local files in unexpected situations (like accepting incoming changes) all my trust for it goes out the window.

Darcy Wiborg-Weber commented Nov 06 '13, 3:30 p.m.

Hi Jens, I'm sorry to hear that you've had a bad experience.

Can you provide more information about the problems you had with local files being overwritten?  Can you point us at a work item?

Jens Melgaard commented Nov 07 '13, 4:28 a.m. | edited Nov 07 '13, 5:02 a.m.


Since the Task and planning part of RTC is so horrible to search in I can't find that for you, (or I won't bother to spent time on figuring it out rather)... I will leave the search to you instead (Eat your own dog-food as they say)... 

I am added as subscriber to a range of issues reported, but I report them internally in our organization and then they report them to IBM so I don't directly have a number or link...

This issue should be in there, it may however be reported under it's root cause which is that you overwrite files at all doing a number of operations: (continued)
(Many might be directly linked to that we use RTC in Visual Studio)

Jens Melgaard commented Nov 07 '13, 4:40 a.m.

RTC Overwrites your local files during these operations where it shouldn't:

 - Accepting incoming changes, although RTC does bring up a dialog stating this and offers to check in changes, this all falls apart combined with the fact that RTC is inherently bad at discovering files that are changed outside your IDE, it also ignores files which you started to change but didn't yet save (which is a DARN common thing)... At the end of the day... This all points to a major flaw in RTC where the relationship between your Sandbox and Workspace is not considered separate streams/branches, but something that should always be in complete sync... Git/SVN/TFS would require you to merge incoming changes into your sandbox, not just overwrite.

 - Synchronizing your workspace and sandbox, an idea that shouldn't even exist, this is considered as an "error" situation, however one that you will easily get into. Basically it seems that canceling any SCM related operation tends to leave you out of sync, like cancel a suspend, check-in etc. (Joke: Maybe write "break my sandbox" on that button instead, it's what it seems to do anyways?)

Jens Melgaard commented Nov 07 '13, 4:47 a.m.
  • The unexplained situations, I have seen other situations than mentioned above, but I have yet to be able to put my finger on it, but it might have been in a combination of things (files not saved, files RTC didn't discover changes it or others).

    At the end of the day, there should be a single situation where RTC reverts your changes, and that is when you ask it to Undo, Discard CS are acceptable situations, although It would be nice if you could say Discard CS and then get the changes down into your sandbox like you can with git, but I think there is other tools in RTC to leverage the use-cases catered by that git feature (e.g. that you can move changes between change sets)

Jens Melgaard commented Nov 07 '13, 5:02 a.m.

 And beginning to talk about Undo and Discard, when it comes to those a new set of issues just arises...

When I have accepted incoming changes and then merged a file and good to go but down the road says... hey I no longer need my own changes to this file because I did a refactoring, guess what I can't do... Undo that file... An operation what would basically put that file in the state it is in the current "head" or change my workspace is currently based on. But RTC denies that possibility... There is a workaround however... Move that merged file into it's own change-set and kill that change-set (discard)... But that is just silly.

I have also been in situations where I can't revert files, even if I wanted to as they would create a fork/conflict... This for a file which when comparing it to the one on the remote stream I am tracking has no changes. Which brings me to yet another thing.

Files that has no changes at all are still recorded as changes in RTC on occasion. Add a line-break, check-in, remove line-break, check-in - file remains a change. And that's what I have time for mentioning for now.

Sreerupa Sen commented Nov 12 '13, 4:14 a.m. | edited Nov 12 '13, 4:15 a.m.

Hi Jens,

    It's unfortunate that you've encountered so many issues with RTC. What surprises me however is that many of the issues you've raised have been fixed in RTC, some of them quite long ago. Discovering files outside IDE for example has been there now for a long time - there's a setting for it. Then there's also a setting that lets you checkin your changes automatically - that would give you the Git/SVN/TFS like behavior when you're accepting changes.The recent merge gap feature would also be of interest to you if you're still using RTC.  
    I guess as an RTC SCM/Client developer it's disappointing to me that as a user you're unhappy with RTC. We can set up calls and talk about the various issues you're still facing if that'd help in any way. Or of configuring RTC in a way that's more usable for you.
    I'm curious to know what version of RTC you're using?
RTC Client Integrations

Jens Melgaard commented Nov 18 '13, 3:44 a.m.

@Sreerupa It is true that back in 4.0.1 the issue with not discovering changes was far more frequent, and I can't say for sure at the moment that it's not the combination of other things that does it. But it still happens in 4.0.4 on a regular basis if your not mindful of it. But you shouldn't need to be mindful of it. Now you say many, that was one "minor one"?

Runining with "checkin your changes automatically" leaves your IDE in a frequent process where it exchanges data with the server (Slow), I have been using it for quite some time to try to mitigate certain things about RTC, but it certainly doesn't give you the same flow as with GIT (DVCS)... It does get one close to SVN/TFS (Centralized).

Jens Melgaard commented Nov 18 '13, 4:17 a.m.
I also can't see how the "merge gap feature" would help me with the more common cases. It may have be able to get me out of some of those insane situations where RTC have locked me down entirely in previously, obviously these are less frequent so I have yet to try that on 4.0.4, only time will tell.

But it doesn't sound like that has anything to do with overwriting changes in the sandbox when accepting changes, or when I get out into that insane "out of sync" situation... Which is the one of highest importance as that is the one causing one to have to redo work...

Changes lost during merge is also sometimes an issue. Somewhat unrelated to the above, and then not entirely.

Sreerupa Sen commented Nov 19 '13, 6:30 a.m.

 Hi Jens,

    The fact that you still have those discovering changes errors still in 4.0.4 are surprising - would you please log a work item on if you see it? If you're using VS Client 4.0.4, then Team Concert->Help->Submit a Bug should do it, Please attach your trace files as well. 
    Yeah merge gaps is nothing to do with overwriting files, for that if you want no-overwrite behavior, you'll have to go with auto check-in. And yes RTC is centralized, we do have support for distributed version control, and in that mode you can work in your local repository in an offline mode, but that would be an overkill IMO in this case.
   As for out-of-sync - are you by any chance loading your repository workspace in different sandboxes and working off more than one of them? Is this something you see frequently? I would like to understand your situation more, since not many people have complained about spurious out-of-sync errors.

Jens Melgaard commented Nov 19 '13, 7:18 a.m.

There should already be a bug around, I am not submitting it then, nor will I because we need to track them internally as well. So I will only ever submit bugs thorough our organization, never directly. That said, I don't have all the scenarios where it happened quite figured out yet, whenever I do I add them as bugs internally and they are passed on to you. So I can only give them as I figure them out.

None of them matters to me, because the one big point here is that RTC allows it self to overwrite my local files in other situations that what should be expected, anything else than undo and revert. This is the core of many of the issue, and its the one single reason why I don't really trust RTC with my files.

I know RTC is a centralized SCM, but you where the one saying ""that would give you the Git/SVN/TFS like behavior when you're accepting changes"" 

Jens Melgaard commented Nov 19 '13, 7:41 a.m.

Auto check-in mitigates some of the many issues I have with RTC, but it also brings a forest of new ones.

And then it is slow as hell, whenever I do a check-in of just a single file, it takes roughly 3-10 seconds to complete, and being one with a habit of pressing CTRL+S up to every second second, then it's a constant process running in the background. That being said, from the moment I save a file till it gets discovered by RTC also leaves a lag period of 2-4 seconds.

Which tells me that RTC isn't really integrated into Visual Studios SCM model correctly, which also explains why RTC doesn't discover a file change before it is actually saved, again leading to data loss if you forget to save that file (as Visual Studio will automatically reload files that changes), taken competitor clients (e.g. Microsofts own GIT Client) whenever I put a single character into a file it immediately pops up in the pending changes window. If I try to commit it without saving it, it asks me if I wish to save it before committing my changes.

Jens Melgaard commented Nov 19 '13, 7:51 a.m. | edited Nov 19 '13, 7:59 a.m.

Out-of-sync was very frequent in a period where I worked across a workstation, laptop and some virtual machines, and I have already had a huge discussion about it in another post.

And there has been a number of suggestions, but none that fits the workflow. E.g. completing changes and sharing them between work-spaces would generate bad change-sets and is more time consuming than e.g. "git push laptop master".

But IBM's clear standpoint is that "It's by design". (IMO Bad design).

Other situations where my work-space has gone "out of sync" is on commands I cancel.

Sreerupa Sen commented Nov 20 '13, 12:50 p.m. | edited Nov 20 '13, 1:12 p.m.

Thanks Jens for sharing your experiences with RTC  - this was a frank if not very productive discussion. We've kind of gotten derailed from the Git vs RTC discussion, because of the questions I asked you I guess, so I'll just stop here. I guess my experiences with RTC VS have been very different from yours but that doesn't get us anywhere, does it!


showing 5 of 13 show 8 more comments

permanent link
N Z (36212127) | answered Nov 10 '13, 4:56 p.m.
Integration is very important, and since you are already using RTC and RQM, then extending the use of RTC to use scm is something that is hard to ignore.

On the other hand, I think the SCM component of RTC is probably the weakest part of the product. Functionally, it's ok, but all the interfaces are poor, limited and/or confusing, including eclipse, lscm, windows explorer and the web interface. In the 2 organisations that had RTC I have worked in, in the first, project teams were given the option of SVN and RTC/scm and after being shown both, and the pros/cons, they nearly always picked SVN, in the other organisation, they use RTC extensively, except for the scm component.

Having said that, you should definitely trial it out, YMMV.

Sreerupa Sen commented Nov 12 '13, 4:26 a.m.

Hi N Z,

    Would you be able to elaborate a bit more  on the RTC interfaces - what we can do to improve them? When you say they're limited, is it w.r.t other competing tools, or you're talking about feature parity between the RTC Clients? For lscm - is it not at par, not consumable easily, or is it's UX an issue? For the Windows Explorer, is it not rich enough or are the work flows not what you expected? Or is it the SCM model that you'd like for us to improve?
    I work on the RTC Clients, and one of my tasks is to improve user experiences on the different clients we have. We've done some good UX/Client parity improvements on some of the RTC Clients this year, but I know that there's a lot of scope for improvement so your feedback would be really valuable.

permanent link
Stuart (61132) | answered Nov 12 '13, 9:06 a.m.
Thanks for all the additional info. If the need ever arises I'll give the revised scm a shot. You have to remember that unlike with git, our team doesn't typically have a choice about what version of scm to use. Our RTC infrastructure is maintained by others and we only recently (within the last 6 months) got a 3.x server. Given how long it took to get there from our antiquated 2.x server, I'm not optimistic that I'd have the opportunity to even try the latest CLI anytime soon. Even if if I could get my hands on the latest version tomorrow, I don't know that it'd be an easy sell on my teams. The ease and flexibility of git (we really like the fact that every cloned copy of a repository is itself a working repository) has really made it the go to scm platform on most of our recent projects. Via gitweb, we're able to almost integrate (close enough for our purposes) our scm and other components.

permanent link
Shawn Pease (3123) | answered Aug 26 '15, 1:23 p.m.

I started to think that this stream of forum posts would be an interesting resource to help answer some questions I have regarding RTC and Git. Then I got to the bottom of these posts.

It seems all of this information relates to an extremely old version of RTC.  Does anyone have any relevant statements regarding recent RTC releases? How does 5.0.2 or 6.0 compare in this space?

permanent link
ian boden (2115) | answered Feb 27 '16, 3:54 p.m.
Shawn don't know if you are still interested but more recent versions of RTC have fixed some problems, but most of the problems people talk about still stand. I worked in a small team using git for a prototype, but then the company wouldn't allow production code to be maintained from git. The production code was predominantly in SVN but with pressure from above we were migrating to RTC.

I really resent the fact that I was forced into RTC and a few months later git was given the green light. That was a fair number of years ago but the cost of migrating to RTC has left us unwilling to migrate to git (not sure if this is fear of how long the migration would take or if it is a need to prove the migration wasn't a complete waste of effort).

If you use git then you get used to working with patch sets and some people will try to tell you these are the same as changesets, they aren't. Patch sets contain changes to a set of lines that may be in a single file or in multiple files, a changeset contains changes to a file or multiple files and the metadata explaining how the file got into that state. A file can only be in one active changeset, if a file is added to a changeset and then an incoming changeset is merged you can end up with the file needing to remain in the changeset even if it no longer contains any changes. This makes merging a complete pain and it is very easy to get something wrong such that you have two streams containing identical code but when a changeset gets added to one stream it has to be manually merged into the other. At this point merging one stream into another is a nightmare. The more recent gap resolution improvements have kind of helped but the GUI has some very confusing and non-intuative options for merging that still make it very easy for people to get it wrong.

So I would argue that stream merges in RTC should be done only by an expert, if you work for a company that invests in a strong infrastructure team and can therefor afford to appoint people to that task then you will have a much better time with it. Alternatively if you are a very small team and so wont need multiple streams you can avoid these problems.

The other major flaw of RTC is that pretty everything you do needs to be done online, both git and RTC give you the option to annotate a file to see what lines were change by who and when, the difference is that git can do this using the information it already has locally, RTC needs to transfer the data from the server, the same is true for looking at the history of a file. Both git and RTC have options to save what you were working on and revert back to an earlier point, in RTC it's suspending, in git it's stashing. Suspending requires a server connection which does means your change is saved remotely, stashing is done locally so can be done when you have no internet connection. Git does allow you to push stashed changes to a remote server so it's possible to back up to a remote server but it isn't done as part of the stash.

If your company doesn't allow people to work from remote locations or the vast majority of the time people are in the office with a decent internet connection then this isn't too much of a problem.

Of course that is all about RTC's source code management, what has changed over the past few releases is that RTC is getting better at working with external tools, for example support for Jenkins has come on massively. One of the things that it does now claim, is that it supports git, previously there was a git bridge which as far as I could tell was useless, but now it can talk directly to a git repository, although I haven't any experience with that.

Using RTC as the hub for you solution and then using git as the repository might be a great place to start, you can then replace different sections of RTC with alternatives if/when it becomes necessary.

There is one feature of RTC's source control that might be important to you, and may be a reason not to go with git. RTC allows you quite fine grained security and I think you can even get logs to find out who has ever checked out a file which for some government contracts may be a requirement. If you do need that security and audit-ability then I'm not aware of an alternative.

Hope that helps.

Geoffrey Clemm commented Feb 27 '16, 5:37 p.m.

I didn't understand the comment: "if a file is added to a change set and then an incoming change set is merged you can end up with the file needing to remain in the changeset even if it no longer contains any changes".
The only time a change cannot be removed from a change set is if you have completed the change set (either explicitly, or implicitly by delivering the change set). 
Also, a change set is a set of changes ... if there no longer are any changes, then there is nothing that could "remain" in the change set.  (Note: I'm not saying you are wrong ... just that I didn't understand what you were saying :-).

ian boden commented Feb 28 '16, 11:10 a.m.

Sorry think I clicked the wrong place and so my reply went in the wrong place. See below.

permanent link
ian boden (2115) | answered Feb 28 '16, 11:09 a.m.
edited Feb 28 '16, 11:36 a.m. by Geoffrey Clemm (30.1k33035)
A change set contains both the change and the metadata*, so say you have made change A to a file, you then merge in change B from an incoming change set, you then decide that you don't need change A as change B is sufficient, you can't remove that file from the change set, if you undo change A such that a comparison to the head shows no differences, it is still in the change set, the only way I know of getting it out of the change set is to create a patch, suspend the change set and the apply the patch and check everything into a new change set that wont contain that file.

*when a I refer to metadata I'm talking about history/merge metadata contained within a change set and not metadata such as the file type, line deliminators etc.

Here is a very simple example using suspend rather than having incoming changes:
Create a text file and add the lines:
Create file
Add to change set and complete!

Add that to a change set and complete it (this step was just to make sure you have a created file and a stable base to work from you could do this to the end of another file if you want and so skip it)

Add another line saying:
Add another line add to change set and complete!

Again add it to a change set and complete it. Now suspend the change set so the file is back to having only the first 2 lines.

Add a new third line saying:
Suspended last change so now add this to a change set but don't complete.

Resume the suspended changeset and handle the merge by having a file with all 4 lines so it looks like:
Create file
Add to change set and complete!
Add another line add to change set and complete!
Suspended last change so now add this to a change set but don't complete.

Now delete the last line so we are back to:
Create file
Add to change set and complete!
Add another line add to change set and complete!

Check that in and you end up with a change set containing a file with no changes in it.
If you try and undo the change then you get the following message
Cannot undo because <file> contains merges. To rollback load the contents of a previous state from history.

Presumably if as part of the merge you realize you don't need the extra line you might be able to do some different kind of merge but the scenario I'm talking about is you realize after the merge has been resolved.

So as to your comment:
"The only time a change cannot be removed from a change set is if you have completed the change set (either explicitly, or implicitly by delivering the change set).  "
That is not true, if it contains merges, hence the existence of that error message.

And for your comment:
"Also, a change set is a set of changes ... if there no longer are any changes, then there is nothing that could "remain" in the change set. "
I wish that were the case, and that is the case if you do the same experiment in git.

This is in 5.0.2 so if something has changed in 6 that gets rid of this really annoying behavior that would be great.

ian boden commented Feb 28 '16, 11:13 a.m. | edited Feb 28 '16, 11:14 a.m.

Can't work out why the bottom of that is all in italics, it isn't when I edit the post!

Update: It appears I may have broken the formatting as everything after my post is now stuck in italics.

Geoffrey Clemm commented Feb 28 '16, 11:38 a.m.

If you go into "html model", you can clean up the italics (I went ahead and did so).
Thanks for the detailed scenario ... I'll play around with it, and see if I discover anything interesting.