Has RTC been already enabled for multi-site use?
Read an article about RTC's funtionality similar to CC/CQ's Multisite at http://jazz.net/blog/index.php/2010/10/04/does-rational-team-concert-support-multisite/.
The author claimed that Rational Team Concert is already enabled for multi-site use but I can'tfigure out how to switch to use RTC to replace my current Multisite configuration. One case is that I have several rmeote sites which own their CC repositories locally and replicate them in read_only copy to us via Multisite which keeps the primary and replicated repositories in sync. by sending sync. packets every 20 minutes automatically. I don't see how RTC can do this as they won't talk to each other as CC servers do via something similar to Multisite. Of course one can say that RTC solves the remote access performance issue and therefore make it unnecessary to own local repository in remote sites. But it is a different approach then. The other case is that I have my primary CC repository replicated to a remote site for disaster recovery. So we can come back to business when our primary site is completely down. On one of the remote site, we setup Multiste repliation server which has read_only copy of every VOBs we have in the primary site and other remote sites and automated Multisite sync. keep the two sites in sync. by sending eachother update packets in time interval we define, like every 10 minutes. When our primary site goes down, all we need to do is to force the read_only replication server to take masterhip of all VOBs and become the new primary one and redirect all users to use it. With RTC, I don't see an easy and similar way to do the samthing. The availability of DB2 HRDAR implementation in RTC 2.0.0.2 offers a way of HA in the same site as Automatic Client Re-routing with HADR and RTC can do it between two DB2 servers: primary and standby. To implement the disaster control, We'll need the third DB2 standby server setup in a remote site but it is not clear how to configure the two standby servers to work with the same primary one. I tried to add th comments to the site where the article is posted but can't get it work. Therefore port it here and hope to get help. |
4 answers
One case is that I have several rmeote sites which own their CC repositories locally and replicate them in read_only copy to us via Multisite which keeps the primary and replicated repositories in sync. by sending sync. packets every 20 minutes automatically. With 3.0 you'll be able to use distributed source control. In that mode, you can set up multiple source control repos that can pass changes around. If you a logical hierarchy of streams, you can put a separate stream on each repo, and have a user promote changes periodically. For example, each team could have their own development stream on the team's repo; when it's judged stable, it could be pushed to a single integration stream on a repo shared by all teams. (You can automate this with shell scripts) Alternatively, the stream could be kept on a central server, but users' workspaces could be farmed out to onto separate repos. If there are network speed or bandwidth issues, this is less desirable than the other approach; although it does allow for users to back their changes up without dealing with a central server. e |
On 2010/10/14 7:53, ghu wrote:
Of course one can say that RTC solves the remote access performance Exactly. If you were using ClearCase Multisite only because your development teams were located at multiple sites, then a single RTC repository can replace all your ClearCase sites just fine. I believe that covers most ClearCase Multisite users. But some ClearCase users, such as yourself, are using Multisite in more innovative ways and getting benefits other than just multiple sites. RTC 1.0 wasn't targeted at those users. (It was impossible to make RTC 1.0 the perfect tool for every development team, so they targeted the more typical development teams first.) Later releases have made progress at being a suitable tool for a wider variety of ClearCase users, but I'm not familiar with the details or whether or not it is a good fit for your team. (Being neither a ClearCase administrator nor an RTC developer, feel free to contradict me or ignore what I say here. I won't be offended.) |
|
David,
Thanks for the comments. Using single RTC repository replace all ClearCase sites is a good idea and is what we are trying to do. And it makes the offsite disaster control ability even more urgent as if your central site vanished for some reason then nobody can work on anything. But in reality, you can't force all teams to use one RTC repository for all kind of reason. So the need to have multiple RTC repositories aross different sites exist. The good news from more reading is that the upcoming RTC 3.0, distributed source control features will be enabled in addition to the central versioning that already exists. This means RTC servers are to be able to talk to each other at RTC level, and that one can now flow components and change sets between workspaces and streams hosted on different repositories. It is not clear though if the work item related to the chageset can also be tracked across the distributed repositories but a great improvement. |
It is not clear though if the work item related to the chageset can also be tracked across the distributed repositories but a great improvement. It is possible for change set links to be maintained as change sets flow between repos. e |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.