[closed] GIT or RTC source control?
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
Comments
Thanks for your answer Millard!
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.
1 vote
@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
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.
Comments
Do you remember what the problems were?
1 vote
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.
1 vote
Many issues discussed here.
1 vote
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).
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 vote
1 vote
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?
@Darcy
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)
1 vote
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?)
1 vote
- 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)
1 vote
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.
1 vote
Hi Jens,
@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).
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,
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.
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.
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.
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!
Comments
Hi N Z,
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?
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
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 :-).
Sorry think I clicked the wrong place and so my reply went in the wrong place. See below.
*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!
Update: It appears I may have broken the formatting as everything after my post is now stuck in italics.
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.
Comments
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER 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
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Sep 21 '23, 6:59 a.m.David and I seem to disagree here 8)