Hi Joseph,

Files are not de-synchronized after resolving a merge, so this is either
pilot error or a bug (I haven't heard of this happening before, so
something unusual must have happened in your case).

Please work with Rational support to find out what happened, and the
support will notify development about what changes might need to be made
to the product or documentation to make sure this doesn't happen.

But note that all history is maintained by both RTC and ClearCase, so it
is guaranteed that you haven't actually lost anything.

Cheers,
Geoff

On 12/15/2010 10:23 AM, joseph wrote:

I follow the "Resolving conflicts during synchronization"
chapter in the RTC 2.0.0.2 document to test file sync between
ClearCase and RTC.

I modify the same file on both RTC& CC then request synch. Every
thing work fine. CC connector shows merge needed. After I resolving
the conflict , I deliver the merge change set. Then I submit a new
synch request.
The build report shows no change happen.
I expect the merged result should be bring over to CC server. But it
didn't.
The file become asynch after conflict/merge. Is it the designed
behavior?

If it's humun error. It's very dangerous because CC-RTC become
asynched without any error/warning.

The only way you could have modified the CLONE workspace would be if you
had logged in using the CC Sync Account. The on-line documentation
states very clearly (in at least 4 places that I know of :-) that you
should *NEVER* log in using the CC Sync Account. This is only to be
used by the CC Sync Engine.

Cheers,
Geoff

On 12/16/2010 10:23 AM, joseph wrote:

gmclemmwrote:
Hi Joseph,

Files are not de-synchronized after resolving a merge, so this is
either
pilot error or a bug (I haven't heard of this happening before, so
something unusual must have happened in your case).

Please work with Rational support to find out what happened, and the

support will notify development about what changes might need to be
made
to the product or documentation to make sure this doesn't happen.

But note that all history is maintained by both RTC and ClearCase,
so it
is guaranteed that you haven't actually lost anything.

Cheers,
Geoff

On 12/15/2010 10:23 AM, joseph wrote:
I follow the "Resolving conflicts during synchronization"
chapter in the RTC 2.0.0.2 document to test file sync between
ClearCase and RTC.

I modify the same file on both RTC& CC then request synch.
Every
thing work fine. CC connector shows merge needed. After I resolving
the conflict , I deliver the merge change set. Then I submit a new
synch request.
The build report shows no change happen.
I expect the merged result should be bring over to CC server. But
it
didn't.
The file become asynch after conflict/merge. Is it the designed
behavior?

If it's humun error. It's very dangerous because CC-RTC become
asynched without any error/warning.

Geoff,

I managed Conflict/merge de-synched problem. The correct procedure
after synch request finished should be:
1. accept change from merge WS<->synch stream.
2. accept change from merge WS<->CLONE workspace
(Conflict shown)
3. Select the file in merge WS<-> Sync stream. Launch
Compare/Merge editor to solve the conflict
4. Deliver change merge result from merge workspace<->synch
stream.
5. Request next synch.

User should not do anything aginst WS<->CLONE after step 2. If
he deliver the change at wrong target , the merged result change set
will gone. Changes will not be detected in next synch. CC-RTC become
de-synched.

Since we need to pilot between two flow-target, it's easy to make
mistake. The user must be well training to aovid error happen.