Topic
  • 7 replies
  • Latest Post - ‏2013-11-07T15:16:46Z by GKellner
JirongHu
JirongHu
683 Posts

Pinned topic Are you staying with CCCQBF or go RTC?

‏2013-11-04T14:51:13Z |

Hi All

I am in Canada and I've deployed three RTC sites. Here almost all the banks, telcos, insurance, governments are using CCCQ based solutions, but so far, none of them are really moving into RTC. In stead, they are moving into v8. A couple of reasons from what I see:

1. RTC can't completely replace CCCQBF.

2. Huge investment already in CCCQBF.

3. RTC is too expensive competing with open source tool such as SVN/JIRA/Hundson and TFS.

My question is:

1. If currently you are a CCCQBF shop, are you staying with CCCQBF or move to RTC?

2. If you are a new shop, will you take RTC?

One thing bothers me is the RTC forum is very active, while here is so cool.

Thanks

Jirong

Updated on 2013-11-04T14:57:29Z at 2013-11-04T14:57:29Z by JirongHu
  • GKellner
    GKellner
    259 Posts

    Re: Are you staying with CCCQBF or go RTC?

    ‏2013-11-05T11:52:53Z  

    We have only CCCQ, not BF actually.

    We won't move existing projects, but if new ones can use the special features of RTC SCM it might start with it.

    Of course, RTC SCM can't replace CCCQ. Have a look at the jazz.net workitems.
    Shops moving from CC to RTC SCM requesting MultiSite, requesting pessimistic locking and so on, just to create a second ClearCase.
    Scalability: One RTC service can support one database, one CC VOB server can support 100+ VOBs.
    But do you want to put 100+ VOB s into one RTC database? Obviously no if they belong to complete different projects.

    So several RTC services instead of one VOB server.

    If you want to speed up the SCM functionality, caching proxies might be a good idea, so for one RTC service one caching proxy.

    For our site there is an easy calculation:
    20 different regions with around 600 VOBs served by six VOB servers.
    If we say one RTC service replaces one region, we would have 20 RTC services plus 20 proxies. Additional proxies on remote sites aren't included.

    Administrating 20 RTC services and 20 proxies instead of six VOB servers sounds good, isn't it? :-D

    Other points: What about business partners, having no direct network access?
    ClearCase MultiSite via ftp, mail, or I've seen an old style ISDN connection.
    RTC SCM - no way.
    Workflow: In CC you can define your own branching strategy, use UCM, use /main/LATEST based on the needs of the project. RTC: You have one workflow, which is similar to UCM.

    So if you have an enterprise kind of view, like banks, governments .. have, RTC (SCM) doesn't seem to be an enterpise system, to much is missing for our daily job.

    But, of course, RTC (SCM) isn't wrong all the time.
    If I think about refactoring huge JAVA projects, it's much more better than CC, due to the complete different file handling.
    If you have small short-term projects (not the huge 30 years development), it can also be usable.

    I heard some IBM technician saying something like: If you start a new JAVA project, use RTC. If you do traditional C/C++ .. development, use CC.
    It's not an official statement, but it is one, which makes sense.

    greetings georg.

  • martina
    martina
    1025 Posts

    Re: Are you staying with CCCQBF or go RTC?

    ‏2013-11-06T01:19:04Z  
    • GKellner
    • ‏2013-11-05T11:52:53Z

    We have only CCCQ, not BF actually.

    We won't move existing projects, but if new ones can use the special features of RTC SCM it might start with it.

    Of course, RTC SCM can't replace CCCQ. Have a look at the jazz.net workitems.
    Shops moving from CC to RTC SCM requesting MultiSite, requesting pessimistic locking and so on, just to create a second ClearCase.
    Scalability: One RTC service can support one database, one CC VOB server can support 100+ VOBs.
    But do you want to put 100+ VOB s into one RTC database? Obviously no if they belong to complete different projects.

    So several RTC services instead of one VOB server.

    If you want to speed up the SCM functionality, caching proxies might be a good idea, so for one RTC service one caching proxy.

    For our site there is an easy calculation:
    20 different regions with around 600 VOBs served by six VOB servers.
    If we say one RTC service replaces one region, we would have 20 RTC services plus 20 proxies. Additional proxies on remote sites aren't included.

    Administrating 20 RTC services and 20 proxies instead of six VOB servers sounds good, isn't it? :-D

    Other points: What about business partners, having no direct network access?
    ClearCase MultiSite via ftp, mail, or I've seen an old style ISDN connection.
    RTC SCM - no way.
    Workflow: In CC you can define your own branching strategy, use UCM, use /main/LATEST based on the needs of the project. RTC: You have one workflow, which is similar to UCM.

    So if you have an enterprise kind of view, like banks, governments .. have, RTC (SCM) doesn't seem to be an enterpise system, to much is missing for our daily job.

    But, of course, RTC (SCM) isn't wrong all the time.
    If I think about refactoring huge JAVA projects, it's much more better than CC, due to the complete different file handling.
    If you have small short-term projects (not the huge 30 years development), it can also be usable.

    I heard some IBM technician saying something like: If you start a new JAVA project, use RTC. If you do traditional C/C++ .. development, use CC.
    It's not an official statement, but it is one, which makes sense.

    greetings georg.

    Good point about needing a bunch of RTC servers.

    You can definitely customize your RTC workflow. You need to get into coding advisors in java. (and you may run into limitations). Term wise, there is some similarity with UCM, but the underlying architecture is totally different.

    If you are in a regulated environment, you will want to look at who needs to be able to modify what how often (add users, change template - needed for some advisors, ...) and how that works with separation of duty.

    I call ClearCase "mature" and RTC a "teenager". The activity on jazz.net shows that. Just like back in the day on cciug.

     

  • GKellner
    GKellner
    259 Posts

    Re: Are you staying with CCCQBF or go RTC?

    ‏2013-11-06T08:06:23Z  
    • martina
    • ‏2013-11-06T01:19:04Z

    Good point about needing a bunch of RTC servers.

    You can definitely customize your RTC workflow. You need to get into coding advisors in java. (and you may run into limitations). Term wise, there is some similarity with UCM, but the underlying architecture is totally different.

    If you are in a regulated environment, you will want to look at who needs to be able to modify what how often (add users, change template - needed for some advisors, ...) and how that works with separation of duty.

    I call ClearCase "mature" and RTC a "teenager". The activity on jazz.net shows that. Just like back in the day on cciug.

     

    Yes, you can definitely modify the RTC workflow itself.
    But the SCM part isn't as flexible as ClearCase.

    So for example a project here:
    - source code in a complex UCM architecture
    - official documents in base CC with branching (release-branch, work-branch, review-branch)
    - other documents and some stuff in /main/LATEST

    Don't know how to put this together in one project area at RTC.

    greetings georg.

  • martina
    martina
    1025 Posts

    Re: Are you staying with CCCQBF or go RTC?

    ‏2013-11-07T00:09:13Z  
    • GKellner
    • ‏2013-11-06T08:06:23Z

    Yes, you can definitely modify the RTC workflow itself.
    But the SCM part isn't as flexible as ClearCase.

    So for example a project here:
    - source code in a complex UCM architecture
    - official documents in base CC with branching (release-branch, work-branch, review-branch)
    - other documents and some stuff in /main/LATEST

    Don't know how to put this together in one project area at RTC.

    greetings georg.

    you would have to "bundle" the streams via naming conventions. The stuff in main/LATEST is in a stream, the docs would be 3 streams that flow, work to review to release.

    For the source code, you'd have to analyze your UCM structure and differentiate between real requirements of your process and things you do 'cause UCM works that way best.

    Then you'd have to find some time to implement, pilot and test it, with some time from your power-developers. And be prepared to tweak it for a few iterations. At this time, I don't know whether you can get it to where you'd want it.

    Also, there is no "pruning" of binaries. Once a version is in RTC it is in there. Since you have docs in CC, the size of the RTC DB could become an issue.

    And currently there is no project move or copy. If you stick something in a server it is in there for good. It one of t he high-pro RFEs, but its been that for a while.

    If you are in an industry that needs to keep things around for 10+ years, you will want to look and forecast before you jump.

    Updated on 2013-11-07T00:11:35Z at 2013-11-07T00:11:35Z by martina
  • martina
    martina
    1025 Posts

    Re: Are you staying with CCCQBF or go RTC?

    ‏2013-11-07T00:23:36Z  
    • martina
    • ‏2013-11-07T00:09:13Z

    you would have to "bundle" the streams via naming conventions. The stuff in main/LATEST is in a stream, the docs would be 3 streams that flow, work to review to release.

    For the source code, you'd have to analyze your UCM structure and differentiate between real requirements of your process and things you do 'cause UCM works that way best.

    Then you'd have to find some time to implement, pilot and test it, with some time from your power-developers. And be prepared to tweak it for a few iterations. At this time, I don't know whether you can get it to where you'd want it.

    Also, there is no "pruning" of binaries. Once a version is in RTC it is in there. Since you have docs in CC, the size of the RTC DB could become an issue.

    And currently there is no project move or copy. If you stick something in a server it is in there for good. It one of t he high-pro RFEs, but its been that for a while.

    If you are in an industry that needs to keep things around for 10+ years, you will want to look and forecast before you jump.

    p.s. having several projects to organize things is an option as well. You can inherit process from a master project. You'd still have to administer the users for 3 projects though.

    At some point finding things and Eclipse performance becomes a challenge.

    Within a project you can also use teams to "own" and "filter" things.

    Lastly, if you are after the Agile planning piece, you can use RTC with CC.

    Since the subject of the thread is also about replacing CQ, you want to look really carefully at your CQ schema and use cases and whether it can be implemented in RTC. CQ customization right now has a few more features than RTC WI customization.

  • GKellner
    GKellner
    259 Posts

    Re: Are you staying with CCCQBF or go RTC?

    ‏2013-11-07T15:08:39Z  
    • martina
    • ‏2013-11-07T00:09:13Z

    you would have to "bundle" the streams via naming conventions. The stuff in main/LATEST is in a stream, the docs would be 3 streams that flow, work to review to release.

    For the source code, you'd have to analyze your UCM structure and differentiate between real requirements of your process and things you do 'cause UCM works that way best.

    Then you'd have to find some time to implement, pilot and test it, with some time from your power-developers. And be prepared to tweak it for a few iterations. At this time, I don't know whether you can get it to where you'd want it.

    Also, there is no "pruning" of binaries. Once a version is in RTC it is in there. Since you have docs in CC, the size of the RTC DB could become an issue.

    And currently there is no project move or copy. If you stick something in a server it is in there for good. It one of t he high-pro RFEs, but its been that for a while.

    If you are in an industry that needs to keep things around for 10+ years, you will want to look and forecast before you jump.

    Reading some discussions regarding the project move, I don't trust this kind of development and I don't trust in the future of RTC.

    They don't have any clue how to split a repository, or brings projects together.
    Obviously they never thought about it.

    A re-organisation of repositories isn't unusual, either due to architectural or ogranisational changes, so splitting repositories is a base requirement, next to diff text files. ;-)

    The WorkItem was submitted in 2009. Bad guys would say: This feature can't be implemented with the current architecture.
    The more features they put onto RTC, it'll be harder to implement this base feature I think.

  • GKellner
    GKellner
    259 Posts

    Re: Are you staying with CCCQBF or go RTC?

    ‏2013-11-07T15:16:46Z  

    Another point to look for:

    Backup/restore.

    If you want to restore only some data or versions you'll have to setup an isolated network with database server, rtc and jts services, hack the jts to get access, and than you can start.

    Isn't as easy as CC, putting the VOB on any CC machine, create local registry and restore the data.