There are two kinds of CC Connectors.
The first (available starting in RTC-1.0) is the "CC Synchronizer".
This copies data from ClearCase a ClearCase stream/branch into an RTC
SCM stream, and then keeps it synchronized.
The second (available starting in RTC-2.0) is the "CC Bridge". This
lets you link an RTC work item to one or more CC UCM activities (similar
to the way an RTC work item can be linked to one or more RTC change
sets), and provides the ability within CCRC to navigate to the work
item, and within RTC to navigate to the UCM activities.

I guess I'm not seeing why I want to link an RTC work item to a CC UCM activity nor why I would need to ever run a CCRC...

WRT the CQ plug-in, I'll look around and see what I can find out.

Thanks. Again, if I can link to Clearcase (i.e. bridge) and link to Clearquest (again, bridge) I'm struggling to understand why I need more than that...

As you know - you do not need to use CC/CQ at all with RTC to get version control and work item management.

I know, but that's not the direction I was headed. As a CC/CQ guy my work usually entails using, well CC and CQ. At home I don't have CC or CQ so I use just CVS.

However, for shops with CC/CQ and that also want to use RTC, the two options Geoff mentions are to help people do that.

Yes they both help you do that. Again, that said, why would I choose one mechanism over the other?

The connectors are useful if you want a clear separation between RTC and CC/CQ and a very carefully managed link between the two "worlds".

OK, so then what does that buy me? Why do I need or care about a clear separation as a developer? I merely wish to develop code and make sure it's checked into CC and/or I wish to refer to CQ activities. You say connectors are useful because they supply a "clear separation". I guess this implies that plugins supply a "fuzzy separation". In any event, why do I care if the separation is clear or fuzzy?

With connectors, each world has its own consistent environment that get's synched up.

Whenever I hear the term "synched up" I think of "extra needless overhead and transferring of data between multiple places". To me it's always seemed best to "work directly with" thus avoiding the needless copying and confusion that results from multiple instances or instantiations of similar objects.

That said, again, it seems like connectors provide separation at the cost of additional work of synchronization while plugins provide a more direct approach. Again, given those choices connectors still do not seem very compelling to me. Or perhaps I'm still missing something...

Each world does not really know about the other (it has no references to RTC inside CC/CQ and visa versa) - the content is created and updated in each world by the connector.

It seems the same can be said for the plugin AFAICT...

A clarification to Anthony's comment below:

The CC/CQ Connectors provide two ways of connecting CC/CQ to RTC.

The first kind of connector (a "synchronizer") acts as Anthony describes
below, i.e. neither world needs to know about the other ... changes from
one world are automatically applied to the corresponding data in the
other world by the synchronizer.

But with the other kind of connector (a "bridge"), the user explicitly
works in both worlds ... the bridge allows the user to create user
visible connections that the user explicitly traverses to view and make
changes in the other world.

Huh? I can't use the CC connector - what you seem to be calling a synchronizer - because we don't have the required CC 7.0 set up. So I guess I'm using the other type of connector which you are calling a bridge. I don't "work in both worlds" as you seem to indicate nor do I "explicitly traverse to view and make changes in the other worlds". Indeed with the CC plugin/bridge I'm in Eclipse and I simply type a character to modify a file that is under CC source control and it checks out the file. I can right click and select Team: Compare with Predecessor and viola! To me this is not really explicitly transversing and working in both worlds - it's an integrated world. How is the CC connector different?

In particular, the CQ Bridge lets you connect one or more CQ records (commonly "requests", but it can be any kind of CQ record) to one or more Jazz work items (commonly "tasks", but it can be any kind of Jazz work item). In this case, the user uses a combination of CQ and RTC for their Change Management system (effectively, some CM record types are stored in the RTC repository as work items, and other CM record types are stored in the CQ repository as CQ records).

The CC Bridge lets you connect one or more CC UCM activities to one or
more Jazz work items. In this case, the user uses CC for their SCM
system and RTC for their Change Management system (and in particular, do not use the RTC SCM system).

One can imagine a variety of other kinds of Bridges (e.g. one connecting
a UCM composite baseline to an RTC baseline), but those have not yet
been implemented.

This would all be encompassed under my question of "Is it just better/tighter integration with Jazz and RTC?". IOW you could of simplified all of this by simply saying "Yes it provides a better/tighter integration with Jazz and RTC".

You would use the CC Bridge to link an RTC work item to a CC UCM activity

CC Bridge or CC Connector? Terms are being thrown about in a confusing fashion. There are two means that I see to have Eclipse (or RTC) talk to Clearcase. One is a CC plugin. This is what I'm using. Then there's the CC Connector for RTC which I cannot use at this time. I think the later is for RTC only and is a synchronizer such that Clearcase remains Clearcase and it's elements and history are imported or synchronized into a Jazz Repository which is used by RTC.

So then is CC Bridge == CC Plugin and CC Connector == CC Connector for RTC?

In any event there is no RTC work item to link to a CC UCM activity as there is no RTC or Jazz servers in my environment. So there's nothing to link a UCM activity to...

if you wanted to use RTC as your change management system, but use ClearCase (and not Jazz SCM) as your SCM system. Since you are using ClearCase as your SCM system, you need a ClearCase UI that is integrated with Eclipse, which is what CCRC provides.

Why do you mention CCRC? I don't use CCRC. I'm using Eclipse straight with the CC Plugin (i.e. bridge). My interactions with Clearcase are provided in the Eclipse UI itself. So how does CCRC come into play?

And if you wanted to use *both* RTC and CQ to do change management (some CM records in RTC and others in CQ), then you would use the CQ Bridge.

I wanted to use a CQ Bridge so that I could gain access to Clearquest information directly in Eclipse. I don't need RTC to do that do I?

If you are happy using CC and CQ, and don't need any of the RTC functionality (e.g. the agile planning capability), then you wouldn't use RTC and therefore would have no need of a Bridge (either CC or CQ).

As I have said several times now - I can't use RTC because CC and CQ at my clients site are not firmly configured to 7.0. When trying to use the CC Connector for RTC I got the to point of trying to connect it to CC and it complained that my CC is not at 7.0. So whether I would like to or need to use RTC is not a relevant question - at this time I can't! Would I like to? Yeah, probably down the road a bit...

I'm not certain what you mean by "Bridge" above and saying that I don't need it. Here's my need: I'm using Eclipse (RTC buys me nothing extra right now until we get to 7.0). In Eclipse I'd like to use CC as my SCM. I'd also like to use CQ directly in Eclipse. I got a CC plugin. Works pretty good. So I scratch my head and wonder out loud "Gee with this working what do I need RTC for?" You say the agile planning capabilities I say "I'm not that impressed with those".

But if other members of your organization are using RTC,

No other members of my organization are using RTC. I already said we aren't even up to 7.0 on CC or CQ...

and they want to see some of your work (either your source code or change requests), then they would have two choices:
- if they are comfortable using CC and CQ, then they would just use the
appropriate CC/CQ Eclipse plug-ins, in addition to their RTC plug-ins.
- if they are not comfortable using CC and CQ, and just want to use RTC
for everything, then you could use the CC/CQ Synchronizers to make the
information you are storing in CC/CQ visible to an RTC user as RTC
artifacts.

We are a CC and CQ shop. We've been this way for quite some time. People use it all the time. Nobody's got RTC - I'm pioneering the effort here so nobody else is even looking at this stuff 'cept me. They are perfectly OK with looking into CC/CQ for anybody's work. Hell not many people are even using Eclipse. I would like to use CC and CQ plug-ins - hell I'm using the CC plugin but can't find the CQ plugin. And quite frankly if I had working versions of CC and CQ that would be more than plenty for me and for most of the clients I have dealt with for the last 10 years.

Note that you wouldn't be using the Bridges in this situation ... the
Bridge is when a single user wants to use *both* RTC *as well as* CC
and/or CQ.

It sounds like what you call a bridge is what is called a Connector elsewhere.

By "clear separation", Anthony meant that a given user doesn't have to know how to use both systems, i.e. a given user can use only RTC or only CC/CQ, rather than having to learn how to interact with both.

We are a CC/CQ shop. People here are comfortable with CC and CQ. They have no burning desire to have "yet another way to do relatively the same thing then have to set up bridges and synchronizers to accommodate different people looking at the same data with different eyes".

Whenever I hear the term "synched up" I think of "extra
needless overhead and transferring of data between multiple
places". To me it's always seemed best to "work directly
with" thus avoiding the needless copying and confusion that
results from multiple instances or instantiations of similar objects.

Yes, there is overhead (i.e. the copying of data by the synchronizer),
but that does run in the background, so it isn't user-visible overhead.
But there is still some human administrative overhead, so you'd only
incur this overhead if you had RTC users that needed access to the CC/CQ info but didn't want to learn how to use CC/CQ (or vice versa).

I don't really care if the overhead is user-visible or not. As the administrator (yes I'm the administrator but I code automation stuff for building and testing etc.) I'm keenly aware of the non-user-visible overhead as well as being the guy doing the "human administrative overhead". My statement was made from that view point in particular. I like to keep things simpler and instead opting for synchronization oriented systems where you essentially have duplicate data and need to maintain a process to keep them current, I'd rather more centralized approaches where people use whatever tools they want to "look into the central repository". IOW more like the plug-in approach than the "let's synchronize things from here to there" approach.

Cheers,
Geoff