Git Outta Here

Lots of people have been liking Git over the last few years. Git is the SCM system created by Linus Torvalds, aka Mr. Linux. But not everyone likes Git and they’re starting to say so.

One of the big knocks against Git is its complexity for the user. The information model, command line syntax, and multiple steps required for basic operations are fine with some people but frustrate others. Steveko’s Blog has a great rundown of many of the difficulties with Git. It’s a good read whether or not you’re a Git fan.

In other Git news, GitHub was recently hacked. There’s a lot of code up there, and now people are worried about the security of their work.

At this point I should warn you that a shameless plug is coming. But since I have no shame…

Rational Team Concert’s SCM systems is philosophically similar to Git’s, but doesn’t load up the user with a lot of extra complexity. Git’s patches are much like RTC’s change sets. Both systems have workspace areas locally and remotely, with separate actions required to move code from your workspace to a common delivery area. There are lots of terminology differences, but many similar perspectives on how to get the work done.

At the same time, RTC manages to keep the code/check-in/deliver cycle reasonably simple. Check-ins can even be done automatically since the code stays in your own workspace (on the server). And RTC provides licenses for small teams (up to 10 developers) when you download the product. At the same time, RTC includes process enactment, project planning, change management, and other goodies.

IBM has also started JazzHub, an SCM hosting environment for academic projects based on RTC. You might want to check this out if you’re part of the academic community.

So if you want a Git-like SCM model plus a lot of other integrated functionality, check out RTC.

And now I’m putting my Shame Glasses back on.

This entry was posted in Uncategorized and tagged , , . Bookmark the permalink.

16 Responses to Git Outta Here

  1. First of all, github is not git. And if you read the article carefuly, not only its title, it says that the RoR was hacked. But thanks to the git brilliant architectural design, it was not dangerous at all: everyone who ever cloned a project has a backup of its history, so, most vulnerabilities cannot put any git managed source code in any significant danger. Not sure about RTC, for me it looks as yet another developer unfriendly Lame Monster® from IBM. One good thing about it – it’s possible to integrate it with git.

    • Kent Dodds says:

      I couldn’t agree with Anatoly more. This article to me seems to be a little unresearched…

    • jruehlin says:

      Well, I did read the article carefully. And to take exception to your comment that Github is not Git, I’ll quote the article: “GitHub is a web-based wrapper around Linus Torvalds’ Git revision control system”. So besides incorporating the name “git” into Github, it wraps a bunch of cool stuff around Git.

      I’m also not arguing with Git’s architecture. I’m disappointed with its usability. The link to Steveko’s blog explains it better than I can in this reply. Even Github, which makes it easier, doesn’t make it truly easy. Part of the reason is that this modern patch/delivery SCM model is more complex then traditional checkin/out, pessimistic locking schemes. But like other products, usability takes a back seat to technology oriented features. So the complexity is something that day-to-day users must deal with. Better usability would result in simple and easy ways for the bulk of users to perform common tasks.

      Finally, the main problem with the hack is not that someone could have maliciously destroyed code, which is very bad. It’s that someone could have stolen the code. Even if someone recovers their code from a clone, they have lost the uniqueness the software represents.

      But I think my main point still stands: Git and RTC are both modern SCM systems with similar philosophies and different terminologies. But Git has some real usability issues (as outlined in Steveko’s blog) that RTC does a better job of dealing with.

      • Ok, let’s compare GitHub with a web-based wrapper around RTC then. Do you have one? And public one, please.

        Honestly, it is quite difficult to compare Git with RTC, because RTC scm just a part of large suite, including project management, issue tracker, etc.
        Patch/delivery model is more appropriate in reality than locks. In real life people work independently unless suppressed deliberately, distributed scm reflects more precisely our Universe. As analogy… consider single threaded programming vs multithreaded. Of course, multithreading is more difficult to grasp, but sorry, single-threading is in the past. And the interesting part is – developers who know multithreaded better write single-threaded code.
        Usability is very subjective, I think that usability of the git is much better than the only monstrous eclipse-based RTC interface with hundred buttons and poor CLI.

        What? If you are pushing a code to a publicly available system, what do you expect? If the code is so precious, have a code in Intranet. There are several systems around – gitorious/gitolite/gitlab.

        RTC is modern, it means only that it’s developed recently, but uses ideas from last century – complex GUI (dialogs with hundred controls), locking, most operations on-line and server-centralised, all-in-one crazy blob of software.

        Regarding the Steveko’s blog.. not sure how to comment it, the blog sounds to me as the latest revelation that the Earth is flat or as a joke like .

  2. Jim Ruehlin says:

    Regarding Anatoly’s comments on 6/15:

    I wouldn’t call RTC’s web-based UI a wrapper. It’s part of the client/server architecture of RTC. There are actually 3 UIs for RTC: web, Eclipse, and Visual Studio. The later two are focused on developers since those are common shells they use. The web client is used by everyone.

    I disagree that it’s difficult to compare Git and RTC. I think it’s pretty easy. As you say, RTC covers much more of the SDLC (though it’s not by itself a suite). So here’s a high-level comparison:
    Git: SCM with a checkin/out and delivery model, optimistic locking (parallel development). Interfaces with a variety of other open source tools. Plus maybe some SCM related stuff I’m missing?
    RTC: SCM with a checkin/out and delivery model, optimistic locking (parallel development). Interfaces with a variety of other tools including open source. Change management that integrates with the SCM for delivery tracking and task management. Project management and planning based on the change management capability. Basic build functionality with integration to other build engines. Process enactment (a very big deal though many organizations don’t realize it).

    So RTC has a similar SCM model as Git, plus a lot more. And it’s free for teams of 10 people or less.

    You seem to think that RTC takes an SVN-type of pessimistic locking approach. This is not at all true – in fact one of my complaints about RTC is that it doesn’t do robust pessimistic locking. Some teams need that. RTC does have the ability to manually lock/unlock individual files, but it’s not a pessimistic locking architecture.

    You also seem to think that RTC only has an Eclipse-based interface. As I indicated above, that’s not true. As far as usability is concerned, Git is organized around a CLI, which is objectively a poor UI. RTC has a CLI which is generally used for scripting.

    I disagree with your assertion that usability is subjective. It’s often assessed subjectively, but there are many objective ways to measure usability.

    And your “hundred buttons” statement is just hyperbole. There is no such dialog in any of the RTC UIs that have anything approaching that many buttons/controls/artifacts. I could go on about usability testing review done at IBM, but suffice to say RTC was built with a robust in mind, while Git was built with a CLI in mind.

    So your second-to-last paragraph is simply incorrect. RTC uses a modern SCM model (similar to Git’s), the UI has nothing like the complexity you claim, it’s locking is manual and not reflective of a pessimistic scheme, and operations are distributed across server and client to balance load and optimize performance.

    I can’t address your last comment on Steveko’s blog because you don’t respond to what he wrote. I think his ideas are clear, thoughtful and interesting, even if you don’t agree with them. You haven’t provided any insight into anything he says. In any case, his blog is a better place to comment on what he has to say. There’s a robust discussion of his article in his comments.

    • Jeff Huang says:

      Jim, I am not sure whether you used RTC or not.

      My team has been using RTC for two years, from RTC 2 to RTC 3 and we are about to upgrade to RTC 4. I hate RTC as a source version control system a lot. And I am afraid my whole team hate it a lot. It dragged our legs, slows down the development, and puts us into a lot of troubles.

      Frankly, the only thing that preventing us from changing to using another one is that I can’t find a convert tool to migrate the repository. If I can find one, we probably want to change it tomorrow.

      My suggestion to other team is: stay away from RTC. If you want to use RTC, use it as a project management system, build link another version control system to it.

      BTW, RTC CLI is far from useful, and it is not cooperative with the GUI, can you imagine that? Maybe I didn’t use it right. Please correct me and help me to make it right.

      • Jim Ruehlin says:

        Jeff, to address your specific comments/questions:

        1. Yes, I have used RTC. I’ve spent the last few years deploying complex RTC configuration into companies large and small across the world. Recently I joined the Process component area of the RTC development team.

        2. I understand you don’t like RTC. But you don’t explain why. How does it slow you down? Poor performance in some area? Difficult usability issues? Bear in mind that there are many things that can affect performance in a complex system. You may not be working on the recommended hardware – see for the recommendations. You may have projects set up in a way that reduces performance. It may even be possible the developers in your organization rightly feel that the process you use in RTC makes them less efficient as individuals. This might be by design – you want the team, as a unit, to be efficient. If the efficiency of some individuals is sacrificed so the team can be more efficient, that’s OK.
        But it’s impossible for me to make observations or give recommendations because you don’t explain what it is that is affecting your efficiency. Bear in mind that the IBM support organization and field organization exist to solve these kinds of issues. Assuming you’re on a maintenance contract, you should contact them for help addressing whatever those issues are.

        3. RTC is actually 5 products: SCM, Change Management, Process Enactment, Project Management, and Build Management. IMO these are all great tools individually, but there’s even more power in using them together. You can certainly integrate different version control systems like Git into RTC. But it’s nice to be able to associate a change set with a work item, to track plans based on that kind of information, assure code is delivered that matches important criteria (updated workspaces, no warnings, copyright statements included, etc). The integration of these features helps to make this kind of powerful process management possible.

        4. Again, you need to provide some information as to what you’re trying to do with the CLI. Perhaps you can already do what you want to do in the GUI but you don’t realize it. Perhaps you don’t need the CLI. Or there’s a way to use it you’re not aware of. Or there’s a bug or problem with the CLI.

        Another rich resource to use to ask these kinds of questions is There are forums with lots of answers, blogs, papers, etc.

  3. This post is clearly biased… And shame on that…

    I have been using RTC for what I think amounts to 3 years now (Can’t quite remember when I got dragged down into this hell hole)… I have also used CVS, TFS, SVN, Mercurial, CC/CQ and Git… And only one on that list is a worse experience than RTC, developed prior to RTC by the same company…

    As a developer RTC is a daily struggle… Not only is it far slower than e.g. Git hosted by Github… Which strikes me as odd since our RTC server is connected in a local network (1 Gbit) where even when I access git-hub over my mobile broadband line (high latency, max 20Mbit) things are still far faster to synchronize… Hell my own hosted SVN server seemed to pull changes back and forth despite having a 1Mbit limit on my upload from home… Now it didn’t start quite that way, so it seems that RTC degrades quite faster than the other alternatives…

    But performance aside, RTC is obviously also bad at actually discovering local changes (Visual Studio Integration), meaning that each time before check-in we need to remember to pull on a “Refresh local and remote changes” which takes about 1-2 minutes to do… (more or less depending on the project size)… If we forget then well… we often brake the build server… And no we don’t use the one delivered with RTC because we found it rather useless compared to the great many alternatives… Won’t go into that..

    Now if it wasn’t bad enough that RTC was bad at discovering changes to your local files, grasp this… When accepting incoming changes RTC simply OVERWRITES your local changes, it does give you a dialog if it has discovered you had local changes, but back to the point above, if it has NOT then it’s to bad, I guess IBM is embracing the “You write it better the second time you write it” philosophy here… But seriously…

    Any company who values there file should take note of this article: Specifically “RTC Source Control’s Backup shed”… IBM sells this as a feature, but it is really a huge indicator of a major design flaw in RTC… Having had to do rework due to RTC several times now has brought RTC in to the same arena as Visual Source Safe, a SCM I don’t trust to keep my files safe… Which leads to manual backup procedures and even more time spent…

    Not to mention that your just at a loss if your work-space goes out of sync… Something that is a ridiculous idea anyways… But that is again due to a design flaw in RTC…

    Github might have been hacked, but that is as hugely stupid point and is in relation to Linux and Apple fanboys continiously argument that “their system is virus free” which obviously is a false argument… If JazzHub ever gets as popular as Github, ill bet you that will be a target as well, and ill bet you that there will be unwanted visitors there as well…

    If you as a company are concerned with Github’s security, then you better host your own SCM tools (E.g. Stash or GitHub enterprise) and cut all wires to the outside world, because if it’s publicly connected, its vulnerable… Ofc. there may be a point in self hosting your stuff and building a secure network around it… It becomes significantly less interesting for hackers than a large public service like GitHub… Just like JazzHub, OSX and Linux is significantly less interesting for hackers…. Again… You can actually host Git your self, and even use awsome tools build around it like Stash or Github Enterprise…

    Git may have a hard to learn Command line, that is because they focused on building a strong and valuable command line up front… And so that is complex… Yes, but there are popping tools up that will help the more novice users (like me) do these (maybe complex tasks?) easily…
    And with those tools, it is in fact easy to use git… Easier than RTC actually…

    And it’s funny you bring complex up as a git disadvantage… Because RTC is not complex???… Wait what?… RTC is about the most complex SCM I have seen… The thing is, Git’s complexity can be hidden away under neat UI’s… RTC’s complexity starts at the GUI which is overly complex, so I am not even sure RTC can be made simple… And then it brings you into odd situations and many of them giving you unexplained errors… Why can’t I undo a Merged file for example?… What is the logic behind that… Undo means revert to the version of the head I am currently pointing no… (Oh but you can by moving it into a different change-set and discarding that… WTF????)… Suspend/Resume feature also sometimes breaks down completely where things can’t be resumed, or is forcing me to complete a change-set before…

    I could begin on the other Parts of RTC that doesn’t have much to do with the SCM, e.g. the horrible task planning system…

    RTC is a huge leap forward compared to CC/CQ, and in the right direction, but it stops there… It is still far from a competitor in my mind, unfertunetly someone had to safe face when we choose RTC, We had spent allot of money on CC/CQ, and even IBM admitted that it was the wrong tool after some time, so someone had to prove that we hadn’t chosen IBM in vain… Fan-F****-Tastic…

    This may seem like a long and emotional rant, and yes it is emotional as RTC wastes hours of my time on a weekly basis… Git hasn’t done so yet, despite working on opensource teams that is far larger then the ones I work on at work…

    • Jim Ruehlin says:

      There’s a lot here so I’ll try to respond to each point.

      I sure hope my bias was clear – I make no bones about working on Jazz-based products like RTC (it’s in the blog’s name). And the original post announced that I was making a shameless plug. Read other responses to the post and you’ll see that everyone is biased. That’s why we all have opinions about this :-).

      Sorry to hear you’re struggling with RTC. Regarding performance vs GitHub, a GitHub (or JazzHub) project is a relatively simple animal. I don’t know, but I’ll hazard a guess that your local system is supporting process enactment, dashboarding, and lots other features that enterprises need but Git alone doesn’t necessarily provide.

      It might also relate to the version you’re using. There were significant performance improvements in version 4.x in a variety of areas. Sometimes organizations wait on their upgrades. But without understanding more about your particular organization, and getting some robust measurements, it’s hard to say why you might be experiencing less performance than others are.

      I’m not very familiar with the VS interface for RTC, but there is an option to automatically detect changes outside of the VS environment. That option is disabled by default, so possibly that isn’t turned on in your environment.

      You can overwrite your local workspace because your workspace actually lives in 2 places in RTC: locally and remotely. If the local part of the workspace – the sandbox – gets trashed, you still have the remote workspace. You just bring it down into a new sandbox. A nice feature, that. You can maintain multiple workspaces with different configurations, and bring down the one you need at the moment.

      If you’re having performance issues, that’s something that can happen in any environment, and the more complex the environment the more likely that can occur. But like I mentioned to Jeff Huang in an earlier response, you paid for the product and you should expect it to help solve your problems. I find that organizations sometimes will sit around being frustrated rather than using the maintenance contract they’re already paying for, I don’t know why. Check out my response to Jeff for recommendations on how to address these issues in a complex environment. And I’ll make the same offer – if you can’t get the problem solved, email me your Help ticket number and I’ll work it from this end.

      I don’t think it’s a “stupid point” to mention that Github was hacked. It’s an important thing to know, if you’re storing your precious source code there. And yes, any popular site attracts unwanted visitors. If the site gets hacked, people deserve to know about it so they can make decisions accordingly, be it Jazzhub, Github, or whoever. People shouldn’t live in ignorance.

      Regarding self-hosting, most enterprises who use RTC do this. I haven’t yet seen a company of any decent size that puts their large projects on the cloud (though some will put lots of their small projects on the cloud after auditing the provider). But that’s one of the reasons why a problem (like performance) can be caused by so many things other than a single product. The cause can often be the interaction between products and systems in a complex environment.

      I think that organizations do want to put more of their projects on the cloud. But they rightly worry about security, reliability, intellectual property rights, etc. As the industry matures and auditing becomes common, I’m guessing you’ll see cloud hosting get more accepted for more complex organizations. That’ll solve a lot of problems (and introduce some new ones :-)).

      My point about complexity in the original article is not that RTC isn’t complex – it is. But it hides the complexity with a great UI. I disagree with you about that – given the SCM model I think RTC does a good job of presenting information and functionality, letting you know the SCM state and the features available. Git is a CLI, so you don’t know what’s available without research, calculation, and typing. You don’t know the state until you query the state manually.

      Yes, there are various UIs being produced for Git. They’ve come along years after Git has been released, and require a separate installation and are supported by a separate organization.

      It’s interesting that people who like Git – who understand its model – have no problem with patches, branches, commits, and the like. But when they look at RTC, these smart people start acting confused about change sets, streams, and the like.

      Git, RTC, SVN, or any SCM system has a model. Part of RTC’s model is that everything is delivered as a change set. So you change a file, those changes get added to the repository in a change set. You change 100 files, those changes can all be part of a single change set (if it takes 100 files to fix a bug). A change set is essentially a transaction. If you need to back something out, that change is… part of a change set.

      I don’t think it’s an issue of RTC being too complex for developers. I think that developers like the model they know. If they know Git (or RTC or SVN), then a different model seems alien for a while.

      Have to disagree with you about IBM admitting that CC/CQ was the “wrong tool”. Where did you get that from? IBM has never made that claim. Those products have been around for around 15 years. New ideas and technologies will eventually overtake older ones that were the best in their day. Doesn’t mean they’re “wrong”.

      • IBM admitting that CC/CQ to being the wrong tool was in the context I wrote it, meaning our situation… IBM admitted that and so we got reimbursed with a number of free Licenses for RTC… Still had to spent more on RTC though.

        It’s not bad to inform people about that GitHub has been hacked, it’s the context you bring it up in, bringing it up as an argument to choose RTC over GIT e.g. which is what you do here… That is a stupid point…

        We are using RTC 4.0.4, I believe that is the latest stable version right?… I do have the option for discovering files changed outside of the IDE automatically turned on (Why is there even such a option?)

        “””I don’t think it’s an issue of RTC being too complex for developers. I think that developers like the model they know. If they know Git (or RTC or SVN), then a different model seems alien for a while.”””

        I have worked with RTC for over 3 years now… “Alien for a while?”… Back when I started working with CC/CQ I was accustomed to CVS and TFS, then short after that I put up my own SVN server, then after a short evaluation of RTC, GIT and Mercurial we switched to RTC in the company (that’s approx 6 months after I got introduced to CC/CQ), despite that the developers said “Mercurial seemed better” (I was not part of the evaluation, GIT was scrapped because of the lack of GUI’s at the time)… and even after 3 years I still find it horrible… I recently, like 8 months ago if not less adopted GIT my self using BitBucket for privates and GitHub for publics… So your assumption here is dead wrong… RTC is not complex because it’s alien to me… RTC’s UI is just purely complex… And thats just for the developers standpoint, I have had a glimpse into the Workitem configuration system and was blown away by it’s horrors… (What IS it with IBM and tree views as the single GUI control to solve EVERYTHING?)

        I don’t know the true status of all the tickets we have reported, because I report them internally to our maintainers, they report them to IBM, they do tend to send me an email with a ticket number but they are never easy to dig up in my mail-storm. But there are many of them that hasn’t been solved yet, and that’s after years on some of them.

        “”I don’t know, but I’ll hazard a guess that your local system is supporting process enactment, dashboarding, and lots other features that enterprises need but Git alone doesn’t necessarily provide.””

        Not in RTC… no one could ever get anything meaningful up and working in RTC, so we gave up… Some projects begin to Adopt JIRA and double tracking… Others… do manual (printed out) scrumboards and burndowns etc.

      • “It’s interesting that people who like Git – who understand its model – have no problem with patches, branches, commits, and the like. But when they look at RTC, these smart people start acting confused about change sets, streams, and the like.”

        It’s interesting but very easy to explain – the terms patches, branches, commits have been in use for years by nearly all source control systems, so of course developers are familiar with them. The terms used by IBM in Clearcase and RTC are unfamiliar. This is a barrier to acceptance, like it or not.

        And IBM don’t exactly make it easy to overcome that barrier. Search Amazon for books on RTC… search Stack Overflow or Server Fault or Nabble for information on RTC, try and find an online interactive tutorial or a beginners’ guide. Anything to compare with for RTC? Surely IBM have the money and the skills to produce something similar for RTC? Why is hardly anyone writing about RTC?

        Developers I speak to claim that although Git’s model is a paradigm shift from Subversion, it’s easier to understand than RTCs. All you have to think about are snapshots of the entire filesystem, and how far your repo clone is behind other clones. “Trivial merging” is often the #1 reason they like Git. Also there’s no GUI to navigate (unless you’re a masochist) and Git is well-supported by all of the major IDEs.

        Another problem with RTC is lack of compatibility with non-IBM tools. You’re selling an “eierlegende Wollmilchsau” and expecting us to love all the features. But what if I prefer JIRA for task tracking, or IntelliJ as my IDE, or Go as my Continuous Delivery engine, or SonarQube (or Clover) as my Code Quality tool? Zero integration available.

        I believe this is why I have witnessed a massive developer rebellion against RTC in the London banking sector over the last two years, where there has been a general backlash against the heavily centralised silos and ivory towers of Operations. This has become known as “DevOps” which, ironically, IBM have tried to capitalise on by purchasing yet another “all-in-one”, admin-heavy build tool (UrbanCode Deploy) that gives Ops teams all the power, and castrates the developers. Way to jump on the DevOps bandwagon and miss… bellyflopping onto the road behind it.

        And I’ve witnessed central Ops teams carrying on oblivious, enjoying the wining and dining from IBM reps and, between them, labouring under the delusion that RTC is some huge success. In reality though, they’re often only “managing” abandoned repos (the dev team may occasionally chuck a bone from Git master branch, just to keep up the illusion), while entire departments have gone native and started hosting and managing their own DVCS repositories, just to be able to get their work done more smoothly (particularly now that most of us in the banks work from home), using the tools they prefer. It’s easily done – the licensing for JIRA + Stash + Bamboo + Confluence for an average sized investment bank department is roughly $10k – $15k per year.

        If IBM really wants RTC to be a success, it needs to get into areas where RTC has been abandoned, and find out why. Talk to developers about why they prefer JIRA, why they like the Git command line, why they find Git easier and more enjoyable to use.

  4. Jeff Huang says:

    1. You deployed RTC for companies, but I doubt you actually use RTC to develop software system. Basically, you could be a salesman or support, am I right? If you are not a software engineer who intensively uses RTC scm for developing software, it is not easy for you to understand the problem.

    2. Yes, it is a big problem in our development cycle. It slows down our development, it adds more overhead, it lacks of features for version tracking. Sometimes when RTC doesn’t work well, our engineers have to go for a walk or have a cup of coffee, so you know how big the problem is? I don’t even think RTC scm could be as good as the old CVS system. And please don’t try to blame the configuration. I am with a big company and we have IBM’s engineers working on site. We pay good money for the system.

    And please try not to argue things like individual should sacrifice for the team’s benefits to me. We have engineers stuck for 30 minutes to wait for Eclipse finishing its work with RTC occasionally. This is not something we could allow a version control system to do.

    3. You put git here as a comparison. So please face the RTC scm problem.

    4. “Perhaps you can already do what you want to do in the GUI but you don’t realize it. Perhaps you don’t need the CLI.” Then, please tell me what to do if I see the “Out of sync” issue in the GUI.

  5. Neil says:

    I haven’t used Git, but I can honestly say that RTC is probably one of the worst SCM systems I’ve every used! As mentioned above, in the 2 organisations I’ve worked that use RTC, no-one bothers with the SCM component. Really, the interfaces are a joke, no-one wants to be subjected to them.

    You can go on as long as you want about the architecture and design, but the reality is, that only now, at RTC 4 is it almost ready for the enterprise. The versions before that were limited and a joke, the best thing about them was your salespeople who were able to foist them onto anyone.

    There are few tools I’ve disliked working with, RTC is one of them, I wouldn’t recommend it to anyone in it’s current form. Apart from the confusing and limited interfaces (which look better in powerpoint slides than in practice), it is a monster to administer.

    Fine, you didn’t have a good experience with Git, but I haven’t, and the organisations I’ve worked with have not had a pleasant experience with the SCM component of RTC. Take off your rose colored glasses, and listen to the people above.

  6. Jim Ruehlin says:

    I do work as a developer, and I’ve also worked with hundreds of customers to improve their SDLC (including SCM). Don’t know why that would make me less qualified to make comparisons.

    It’s hard to respond to general comments about how RTC slows you down. I’d need to know how you’re slowed down in order to make any comparison. Unlike collections of small teams, an enterprise environment will often require more process enforcement and data collection through a tool so management can get the reports and dashboards they want.

    Waiting 30 minutes to finish a delivery is, of course, unacceptable. But from what you said, you may not be delivering something, and it happens infrequently. The problem might be an RTC configuration, or a network latency problem, or a 3rd party Eclipse plugin, etc, rather than an inherent problem with RTC. So again I can’t make any specific comparisons.

    All that said, your comments have taken us from a philosophical/architectural discussion of “RTC sux and Git is great” to specific complaints you have in your environment. The fact is, you paid for the tool and you deserve to have it work in a way that fulfills your needs. You probably pay for maintenance, so if you haven’t already, you should:
    Contact IBM support and demand any issues you have get fixed (poor performance, things that don’t work, etc)
    Contact your sales rep and rattling his/her cage to get someone out to evaluate your configuration. If you work for a large company it’s probably complex, and there are likely things that can be done to improve it.
    Search and/or post on the forums to see if you can resolve your issue there.

    If you can’t get satisfaction from these methods, please contact me ( with your Help ticket number. I’ll work it from the inside to help get your problem gets resolved.

  7. Cassa says:

    Nice to read different opinions about RTC vs the Others.

    I have been working in the SCM area for more than a decade, and I have seen lots of success and failures. Those success do not only depend on tools neither on people, but only to good procedures and approaches. But let me say this: if your environment sucks, it does not matter how good is your procedure, a failure is around the corner! After all, a good pilot is not a good one if it drives a crappy car.

    I am ClearQuest and ClearQuest fan, I did pretty good jobs with those tools, they have a logic and you can plan ahead. Let me be honest here, JAZZ-RTC is simply madness. Full stop!

    Although I have to admit that I started to hate ClearCase and ClearQuest too in particularly from version 8.0 because IBM managed to kill this powerful and amazing tool. C’mon you cannot have a 20Gbit installation area, and push 8-9Gbit on client installation, be realistic IBM ad admit that this is not an healthy approach!

    My mathematical mind screams and wants to take a vacation when dealing with the illogicality of the JAZZ tool and the approach it uses. I have been trying to support, educate myself, troubleshoot the tool ……. I simply cannot get around the working logic. It has no SCM no SCCM no VA-VA-VUM!

    I stumble across this portal because, like most of the people that have replied and the ones that just read it, are seeking for help and for support and maybe some answers. There are no real answers on the JAZZ portal only replies like . Not nice!…. sorry people this is my feeling

    Well considering that I have read enough comments on the web and on various portals and my direct experience I have to say that the more I read the more I am convinced that JAZZ is not a tool. The majority and —–reoccurring comments——- start with “how does it work JAZZ” gives it away its not usability. And this tool wasn’t released yesterday, and if people are still stuck on square one you never get this kite flying, I’d say.

    The funny thing that I have noticed is that only unskilled people are able to use it, the ones that have no methodical approach, the ones that click here and there, until a green light is on. Do not be offended “otherwise-smart-people” please, please, please share with us your secrets!
    Do these people care about the outcome? Do they know what they are doing? Do they really care or they just wait 5 pm? Well answer these questions when you software is failing you.

    In short and IMHO I do not see this tool to have a very health life in real development environments, there is too much overheads too much maintenance too much additional problems …… well this is my view, you of course please follow your heart.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s