We are currently using CQ and CC with UCM integration. Looking @
using RTC for distributed teams, and using the CC and CQ connectors
built into RTC for synchronizing code/work items.

1. Is there anyone who uses these connectors in a production
environment? I'm looking for any anecdotes for how well they
*really* work. As these are "connectors" between disparate
systems, our management is somewhat leery about these being fragile
and causing more issues than they solve.

2. Let's say we've got 50 developers using RTC, and all 50 of those
have code that will be synchronized into CC. We will of course have
the 50 developer licenses for RTC here. Are there any additional
licenses that will need to be purchased? IE, I've seen in our trial
that there is a "ClearCase Connector license", but I am
unsure if we need just one of those across the board, or one per
user?

3. Same question as #2 for CQ... How many licenses?

4. When code is sync'ed over to CC with the UCM integration, does it
handle picking up the correct CC/CQ "activity" so that in
CC, another dev/CM person can see what CQ record is associated with
the code commit?

Geoff,

Thanks for the info!! That technote was very interesting! Wish I had
seen that a couple of weeks ago :) We actually did get the CC
connector working on our trial copy, and did a few experiments with
it, and it worked. I never did try anything like deleting files, or
moving files, or renaming files/directories -- does that synchronize
across correctly as well?

Like I've said on some of my other posts, this is an incredible
product... You guys did an amazing job!! I'm still pushing for
adoption in my org, and we're just working through "the
wickets," like getting these connectors working. Next up -- the
CQ connector and UCM :) Which leads me to my next question, which is
really just a restatement of my last question on the previous post.
Let's say I am working in RTC, but my org at the "top" is
using CC/CQ with UCM integration. If I associate the correct RTC
work items with a changeset, and then the synchronizer runs, will
those checkins that get put into CC by the synchronizer be
appropriately marked with the correct activity? (IE, I am asking
about RTC -> CC; I think you answered CC -> RTC?)

Regards,
Mike

gmclemmwrote:
WRT the behavior from RTC -> CC, it's the same as the behavior
from CC
-> RTC, namely, only the latest versions from the RTC stream will
be
carried over (not the intermediate versions), but that when the sync
is
done, it will annotate the resulting UCM activity with the list of
Jazz
work items that contributed to the changes since the last sync.

With regards to that statement, does it still play well if we have
CC/CQ integration enabled for UCM? IE, activities are really just CQ
records, which are themselves "sync'ed" to RTC work items?

Thanks,
Mike

gmclemmwrote:
Yes, if you are using CQ-enabled UCM, and the CQ synchronizer, then
each activity is CQ activity (linked to a CC activity), and that CQ
activity is synchronized with an RTC work item (and that RTC work
item is linked to the appropriate change-set created by the CC sync
process).
Geoff, after looking @ the article that jrvasta links to, I am not
sure whether or not this is correct. Can you confirm? If I look at
the article, it seems to state that when code is sync'ed from RTC to
CC, then a *new* UCM activity is created that contains all of the
code changes that need to move over. Then that UCM activity has some
text inserted in its description that says "Synchronized Task:
work>". So it seems that the UCM link between the code
in CC and the records in CQ is lost, because it doesn't really
associate between the code->CQ record UCM activity, but from the
code->some new UCM activity created expressly for checking in code
in CC. (The activity title seems to be "Record created for
ClearCase Connector.")

Like jrvasta said, this is an old 1.0 article, so I am hoping that
maybe this behavior has changed for 2.0? If I am reading it right,
it seems like the whole point of the UCM integration (linking CQ
records->code changes in CC) has been lost...?

Thanks,
Mike

Geoff,

Thanks for the info! Below I describe what I think is happening, and
I just want to make sure I understand what's going on before someone
else asks me about this on our team:

1. Let's say that, as a dev, I am working on one particular work
item/CQ record (because they are synced). And I check in, say, 5
files once a day for this work item. Then let's say I work it for 10
days. Let's also say for simplicity that I am the only one working in
this RTC stream/CC sync'ed stream.
Does this mean, at the end, that I would end up with 10 different UCM
activities (one per day because that's the only time that the sync
picks up anything)?

And the 10 UCM activities would have the same 5
files in them, just in different states? So I think this means I
cannot select the single UCM activity in CC (the one associated with
the RTC work item) to see a single view of the code changes that make
up that activity, right? (The code changes are scattered across the 10
different UCM activities that correspond to the 10 rounds of
synchronization...?)

2. Now take the previous situation and reverse it. Let's say I have
10 devs working on a RTC stream/CC sync stream. They each check in 5
different files for 10 different work items/CQ records.

Does this mean that for each "round" of synchronization
there is always one UCM activity created, with 50 files in it, whose
description contains the headlines for all 10 work items? This would
mean, I think, that there's no traceability from the individual code
changes back to the individual work items, right?