What kind of a workaround did you have in mind? In particular, if the
file that the sync needs to update is reserved by another user, what
alternative does it have other than failing until that file is no longer
reserved?

In general, the way to guarantee this won't happen is to allocate a
separate dev stream for synchronization, rather than synchronizing with
the integration stream. This not only ensures that a checkout in the
integration stream will not interfere with synchronization, but also
ensures that the synchronization (which locks the stream while it is
ongoing) does not block users attempts to deliver to the integration
stream. This does of course require that you deliver/rebase that dev
stream periodically.

Cheers,
Geoff

gdang wrote:

When CC synchronization was kicked off, one file to be synchronized
was checked-out (reserved). The synchrinization faield since it also
tried to checkout the same file in reserved mode. We could ask all
users to checkout all files before sync. But, I'm wondering whether
there is work around? Thanks.

You can still create a separate sync stream for a single-stream project,
but you will have to create it in a different project, and enable
"cross-stream delivery" for both the single-stream project and for the
project containing the separate sync stream.

Skipping files that are checked out to another view will result in a
corrupted configuration, so no, I wouldn't want to do that (:-).
Similarly, doing an unreserved checkout won't help, because the
subsequent checkin will be blocked by the reserved checkout from the
other view.

Cheers,
Geoff


gdang wrote:

Thanks, Geoff. One RTC pilot project is using single stream UCM
project and thus, we cannot create a development stream. I was think
about whether RTC has the capability of using non-reserved checkout
or simply skip files that being checked out in CC (too crazy?)

You can't declare a sync-stream to be uni-directional, but you can make
it act uni-directional if you don't deliver any changes to the sync-stream.

In this case the ClearCase stream will be locked during the sync (to
ensure it brings over a consistent configuration), but reserved
checkouts will not be an issue, because that only affects outgoing
synchronizations.

So in general, reserved locking only blocks outgoing changes to a
checked out file/directory. So no incoming change is blocked by a
checked out file/directory.

Cheers,
Geoff

gdang wrote:

Is it possible to make the RTC/CC synchronization uni-directional
(only from CC to RTC)? One project is only interested in 'viewing'
verionable objects in RTC and all changes will be made in ClearCase.


For such a uni-directional sync (if possible), will the ClearCase
stream be locked, will reserved checkout still be an issue?

In addition, when will a reserved locking block synchronizatio
(inbound or outbound)? Thanks.

gdang wrote:

It is OK for us to ask our projects not to deliver any changes into
the CC Sync streams. The follow up questions are:
1. Is there any setting in RTC to enforce that users will not be able
to deliver into the CC sync stream (to reduce the number of human
errors), or is this soly an educational process to the project
team/users?

You can use process to enforce this. In the team area that owns the
synchronized stream, only give the ccsync account permission to deliver
to the sync stream.

2. In the window of "Select Files to Synchronize", there are
two radio buttons - "Select files and folders in ClearCase"
and "Select files and folders in Jazz". If we 'never'
choose the 2nd one, does this mean no file will go outbound?

No, those radio buttons just specify which repository will contain the
"source" for the new synchronized file/folder. Once a file/folder is
synchronized with a file/folder in the other repository, it is always
synchronized in a bi-directional fashion.

3. What users have rigts to request a sync?

No rights are required ... any user can request a sync.

Do they need ClearCase Connector licenses to do so?

No, the ClearCase Connector license can only be used by the
synchronization account (not by a human).

If we limit the number of users who are
granted the CC Connector licenses, will that help reduce the chance
of outboud sync?

No, those are unrelated. An outbound sync will occur if you have let a
user deliver to the sync stream ... preventing that is done with process
controls. Human users should never be granted a CC Connector license,
but even if they were, that would not affect whether an outbound sync
could occur.

I actually do not quite understand why so many (250)
CC Connector licenses are available in the Standard RTC Edition.

This just says that you can have an effectively unlimited number of
synchronization accounts. You can decide to just use one
synchronization account for all synchronized streams, or you could
decide to use a separate synchronization account for each synchronized
stream. The advantage of the former is you just have one account to
administer, but this has the disadvantage that if that account gets
locked out (because of login/password problems for example), it will
lock out all sync requests. Also, some people might be interested in
which synchronization stream a given change-set originated from, and
that information is easily available only if each sync stream has a
separate sync account.

Cheers,
Geoff