[closed] GIT or RTC source control?
Leonardo Marzo (249●6●48●52)
| asked Feb 04 '13, 1:18 p.m.
closed Sep 21 '23, 6:56 a.m. by David Honey (1.8k●1●7)
Hi,
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.
Regards,
|
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
Millard Ellingsworth (2.5k●1●24●31)
| answered Feb 04 '13, 8:00 p.m.
FORUM ADMINISTRATOR / JAZZ DEVELOPER
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:
RTC Git Integrations
A slightly older discussion at StackOverflow: http://stackoverflow.com/questions/9369516/using-git-with-rtc-how-about-rsync
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
Comments Thanks for your answer Millard! 1
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. @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
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. |
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.
Jirong
|
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.
Comments 1
Geoffrey Clemm
commented Jul 02 '13, 11:05 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Do you remember what the problems were?
1
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.
Geoffrey Clemm
commented Jul 02 '13, 4:50 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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).
1
Sreerupa Sen
commented Nov 12 '13, 3:55 a.m.
| edited Nov 12 '13, 3:56 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
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. 1
Sreerupa Sen
commented Nov 12 '13, 3:56 a.m.
| edited Nov 12 '13, 3:57 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
showing 5 of 6
show 1 more comments
|
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. Comments 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?
1
@Darcy
1
RTC Overwrites your local files during these operations where it shouldn't:
1
1
And beginning to talk about Undo and Discard, when it comes to those a new set of issues just arises...
Sreerupa Sen
commented Nov 12 '13, 4:14 a.m.
| edited Nov 12 '13, 4:15 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
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?
Cheers
--Rupa
RTC Client Integrations
@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"?
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. 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 jazz.net 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.
Cheers
--Rupa
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.
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""
Auto check-in mitigates some of the many issues I have with RTC, but it also brings a forest of new ones.
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.
Sreerupa Sen
commented Nov 20 '13, 12:50 p.m.
| edited Nov 20 '13, 1:12 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
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!
Cheers
--Rupa
showing 5 of 13
show 8 more comments
|
|
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.
|
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? |
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. Comments
Geoffrey Clemm
commented Feb 27 '16, 5:37 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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".
Sorry think I clicked the wrong place and so my reply went in the wrong place. See below.
|
|
ian boden (21●1●5)
| answered Feb 28 '16, 11:09 a.m.
edited Feb 28 '16, 11:36 a.m. by Geoffrey Clemm (30.1k●3●30●35)
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: STEP 1 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) STEP 2 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. STEP 3 Add a new third line saying: Suspended last change so now add this to a change set but don't complete. STEP 4 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. STEP 5 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. Comments Can't work out why the bottom of that is all in italics, it isn't when I edit the post!
Geoffrey Clemm
commented Feb 28 '16, 11:38 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
If you go into "html model", you can clean up the italics (I went ahead and did so).
|
Comments
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.
David and I seem to disagree here 8)