ClearCase Connector lock UCM stream

Good suggestion, thanks! I've filed workitem 67842 on this.

Cheers,
Geoff


eanderso wrote:

A ClearCase synchronization job attempted to run while someone was
rebasing the UCM stream. The log correctly identified the condition,
but unlocking the stream through the synchronization properties didn't
work or fail in a meaningful way (note: the stream needs to be
unlocked before the rebase can proceed or be cancelled).

I had to unlock the stream using ClearCase and then cancel the rebase
before I could run the sync job.

It would be better if the connector checked the status of the stream
before locking. It would prevent this problem and potentially
interfering with a rebase that was merging (mine wasn't merging at
the time).

We implemented our own "lock" operation, which simply writes a property to
the stream
object. The Unlock button simply removes this property from the CC stream,
thus making
the stream available for other sync jobs to use. So when you unlocked,
nothing actually
happened, as we hadn't locked the stream ourselves and so the property
wasn't there and
there wasn't anything to unlock.

What you did was the proper steps to allow the sync job to run.

I'm a little confused though, you say it would be better if we checked the
status of the stream
(I assume you mean the lock status) before locking it. Isn't that what we
did? Or are you
saying we checked the status, but then went ahead anyway? If so, that
latter would
definitely be worse.

And perhaps we should change the name of our Unlock button to make it more
clear
that it's not the CC operation (perhaps Unreserve?).

--
Brian Nelson
Jazz ClearCase Connector Team

"eanderso" <erik_anderson> wrote in message
news:gkkspg$7pr$1@localhost.localdomain...

A ClearCase synchronization job attempted to run while someone was
rebasing the UCM stream. The log correctly identified the condition,
but unlocking the stream through the synchronization properties didn't
work or fail in a meaningful way (note: the stream needs to be
unlocked before the rebase can proceed or be cancelled).

I had to unlock the stream using ClearCase and then cancel the rebase
before I could run the sync job.

It would be better if the connector checked the status of the stream
before locking. It would prevent this problem and potentially
interfering with a rebase that was merging (mine wasn't merging at
the time).

The sync job locked the UCM stream - I see it in the UCM stream history:

--01-13T15:07 jboyd unlock stream "jhill_LC2.5_sn.mob.core_jazzsync"
--01-13T15:07 jboyd remove attribute "com.ibm.team.interop_RESERVED_FOR_INTEROP" from activity "jhill_LC2.5_sn.mob.core_jazzsync"
--01-13T15:01 jboyd make attribute "com.ibm.team.interop_RESERVED_FOR_INTEROP" on activity "jhill_LC2.5_sn.mob.core_jazzsync"
"Added attribute "com.ibm.team.interop_RESERVED_FOR_INTEROP" with value "STREAM%7Cstream%3Ajboyd_LC2.5_sn.mob.core_jazzsync%40%5Csocnet.projects"."
--01-13T15:01 jboyd lock stream "jhill_LC2.5_sn.mob.core_jazzsync"
"Locked except for users: jboyd"

but the sync job failed because the stream was being rebased. Note: UCM rebase does not lock the stream, it uses some other mechanism to block checkouts while a rebase is in progress:

action: SYNCHRONIZE
synchronization stream location string: Stream|URI:itemOid/com.ibm.team.scm.Workspace/_Qw-UYLG-Ed2KiPZl_obo2Q
synchronizer version number 'I20081024-1335'
running on host 'LCMOBILE'
Creating baseline in component: socnet.sn.mob.web
Computing changes in component: socnet.sn.mob.web
Computing changes in synchronized stream
Computing synchronized roots in other repository
Updating folder: socnet.07/sn.mob.web/lwp/Connections_Mobile_Server/src/main/webapp/javascripts
Updating file: socnet.07/sn.mob.web/lwp/Connections_Mobile_Server/src/main/webapp/javascripts/prototype.js
Synchronization exception: Failure while trying to execute cleartool command:

cleartool checkout -nc W:/DO_NOT_USE_jboyd_LC2.5_sn.mob.web_jazzsync/socnet.07/sn.mob.web/lwp/Connections_Mobile_Server/src/main/webapp/javascripts/prototype.js

cleartool: Error: Checkouts disallowed in view "DO_NOT_USE_jboyd_LC2.5_sn.mob.web_jazzsync": a rebase is active using view "eanderso_jboyd_LC2.5_sn.mob.web_jazzsync" on this stream.
cleartool: Error: Unable to check out "W:/DO_NOT_USE_jboyd_LC2.5_sn.mob.web_jazzsync/socnet.07/sn.mob.web/lwp/Connections_Mobile_Server/src/main/webapp/javascripts/prototype.js".

current working directory: W:\DO_NOT_USE_jboyd_LC2.5_sn.mob.web_jazzsync
command result status: 1
command duration: 172 ms

I assumed the JAZZ unlock released the sync job AND unlocked the UCM stream but as you pointed out, it only does the former.

Since a sync job will always fail if the UCM stream has a rebase in progress, it would be better to have the sync job check the UCM stream for a rebase in progress and fail gracefully rather than leave the system in limbo.

Ah, I see, we did a checkout and THAT's when we found out the stream was
being
rebased.

Okay, I agree with you that we should find a way to check for this condition
and simply
fail the operation rather than attempt to do something we know won't
succeed.

I was about to file a bug, but looked for work items with "rebase" in them,
and found that
Geoff also agrees:

Fail an attempt to lock the CC stream if it is in the middle of a rebase
(67842)


--
Brian Nelson
Jazz ClearCase Connector Team


"eanderso" <erik_anderson> wrote in message
news:gklif5$hr7$1@localhost.localdomain...

The sync job locked the UCM stream - I see it in the UCM stream
history:

--01-13T15:07 jboyd unlock stream
"jhill_LC2.5_sn.mob.core_jazzsync"
--01-13T15:07 jboyd remove attribute
"com.ibm.team.interop_RESERVED_FOR_INTEROP" from activity
"jhill_LC2.5_sn.mob.core_jazzsync"
--01-13T15:01 jboyd make attribute
"com.ibm.team.interop_RESERVED_FOR_INTEROP" on activity
"jhill_LC2.5_sn.mob.core_jazzsync"
"Added attribute
"com.ibm.team.interop_RESERVED_FOR_INTEROP" with value
"STREAM%7Cstream%3Ajboyd_LC2.5_sn.mob.core_jazzsync%40%5Csocnet.projects"."
--01-13T15:01 jboyd lock stream
"jhill_LC2.5_sn.mob.core_jazzsync"
"Locked except for users: jboyd"

but the sync job failed because the stream was being rebased. Note:
UCM rebase does not lock the stream, it uses some other mechanism to
block checkouts while a rebase is in progress:

action: SYNCHRONIZE
synchronization stream location string:
Stream|URI:itemOid/com.ibm.team.scm.Workspace/_Qw-UYLG-Ed2KiPZl_obo2Q
synchronizer version number 'I20081024-1335'
running on host 'LCMOBILE'
Creating baseline in component: socnet.sn.mob.web
Computing changes in component: socnet.sn.mob.web
Computing changes in synchronized stream
Computing synchronized roots in other repository
Updating folder:
socnet.07/sn.mob.web/lwp/Connections_Mobile_Server/src/main/webapp/javascripts
Updating file:
socnet.07/sn.mob.web/lwp/Connections_Mobile_Server/src/main/webapp/javascripts/prototype.js
Synchronization exception: Failure while trying to execute
cleartool command:

cleartool checkout -nc
W:/DO_NOT_USE_jboyd_LC2.5_sn.mob.web_jazzsync/socnet.07/sn.mob.web/lwp/Connections_Mobile_Server/src/main/webapp/javascripts/prototype.js

cleartool: Error: Checkouts disallowed in view
"DO_NOT_USE_jboyd_LC2.5_sn.mob.web_jazzsync": a rebase is
active using view
"eanderso_jboyd_LC2.5_sn.mob.web_jazzsync" on this stream.
cleartool: Error: Unable to check out
"W:/DO_NOT_USE_jboyd_LC2.5_sn.mob.web_jazzsync/socnet.07/sn.mob.web/lwp/Connections_Mobile_Server/src/main/webapp/javascripts/prototype.js".

current working directory:
W:\DO_NOT_USE_jboyd_LC2.5_sn.mob.web_jazzsync
command result status: 1
command duration: 172 ms

I assumed the JAZZ unlock released the sync job AND unlocked the UCM
stream but as you pointed out, it only does the former.

Since a sync job will always fail if the UCM stream has a rebase in
progress, it would be better to have the sync job check the UCM
stream for a rebase in progress and fail gracefully rather than leave
the system in limbo.

Actually, the CC Connector "lock" operation both writes an attribute to
the CC stream and applies a CC lock to the stream (so that another
client doesn't change the stream while the sync is being performed).
The CC Connector "unlock" operation removes both the attribute and the lock.

So the CC Connector "lock" operation will fail if a normal CC lock
cannot be applied to that CC stream.

But I was not able to reproduce the problem Erik describes, so I posted
a question for Erik in workitem 67842 (let's move the discussion on this
issue to that workitem).

Cheers,
Geoff

Brian Nelson wrote:

We implemented our own "lock" operation, which simply writes a property to
the stream
object. The Unlock button simply removes this property from the CC stream,
thus making
the stream available for other sync jobs to use. So when you unlocked,
nothing actually
happened, as we hadn't locked the stream ourselves and so the property
wasn't there and
there wasn't anything to unlock.

What you did was the proper steps to allow the sync job to run.

I'm a little confused though, you say it would be better if we checked the
status of the stream
(I assume you mean the lock status) before locking it. Isn't that what we
did? Or are you
saying we checked the status, but then went ahead anyway? If so, that
latter would
definitely be worse.

And perhaps we should change the name of our Unlock button to make it more
clear
that it's not the CC operation (perhaps Unreserve?).

eanderso wrote:

A ClearCase synchronization job attempted to run while someone was
rebasing the UCM stream. The log correctly identified the condition,
but unlocking the stream through the synchronization properties didn't
work or fail in a meaningful way (note: the stream needs to be
unlocked before the rebase can proceed or be cancelled).

I had to unlock the stream using ClearCase and then cancel the rebase
before I could run the sync job.

It would be better if the connector checked the status of the stream
before locking. It would prevent this problem and potentially
interfering with a rebase that was merging (mine wasn't merging at
the time).