Kenneth,
Your suggestion is a very good one. However, I'm a bit leery of it. The
hitch (at least with 4.0) is that, triggers can't be directly associated to
the new UCM-related VOB objects like "stream" and "activity". An operation
like "mkactivity" or "mkstream" will probably kick off a chain of events,
one of which I can intercept with a trigger. However, by that time UCM may
have done things that I would very-much want to roll back. I'm not sure
that I could reliably figure out what those things were, so I might not be
able to cleanly cancel some operation.
Rational says that those new UCM objects are "first-class" objects, and
that ClearCase attributes and labels can be attached to them. I'm
struggling with that idea. There are no ClearCase types: "activity" or
"stream". I'm used to attaching triggers to "types". To give me a model
that I'm used to, I hope that a later ClearCase release will have these
object "types", and that I will be able to use triggers to trap operations
that seek to change those types.
Thanks,
Dan
From: kleach2@csc.com on 02/22/2000 07:33 PM GMT
To: Dan Rickhoff/US/Centigram, cciug@rational.com
cc:
Subject: Re: [cciug] UCM - Allowing only "pull" deliveries to project
intgrtn strm
Although I have not yet upgraded to 4.0 and will not be using the UCM model
right away, I believe you can accomplish this by using ClearCase triggers.
I am
not sure of the UCM commands that are available for triggers but at a
minimum
you could write pre event checkin triggers, for the main branch, to check
for
the users identity. If the user is not on a valid list, the trigger would
fail
not allowing that user to checkin on the main branch.
Hope this helps.
Dan.Rickhoff@centigram.com on 02/22/2000 02:25:43 PM
To: cciug@rational.com
cc: (bcc: Kenneth R Leach/CIV/CSC)
Subject: [cciug] UCM - Allowing only "pull" deliveries to project intgrtn
strm
CCIUG,
QUESTION:
How can we force UCM to allow only "pull" deliveries to the UCM project's
integration stream?
One Possible ANSWER:
Use MultiSite to set up a (virtual) site where every project stream (and
its associated branch) is mastered, but at which no development streams are
mastered.
BACKGROUND:
We are planning to use MultiSite to replicate VOBs between our two
geographically separated sites, San Jose and Rockville, Maryland. We are
also planning to use ClearCase 4.0's Unified Change Management (UCM) at
both sites.
Consider a particular UCM project whose integration stream (and hence its
associated branch) is mastered at one of the sites, say San Jose. Because
of that mastership, Rockville's developers working on that project cannot
checkin to the project's branch. UCM provides for this case: when a
Rockville developer begins a "deliver" activity, UCM immediately "posts"
that delivery activity for completion by someone at the San Jose site,
i.e., by someone who can actually checkin to the UCM project's branch.
The UCM manuals indicate that the intention is that the "someone" is a
privileged user, either the project's designated integrator or the Release
Administrator.
As a Release Administrator, I like this. The developers don't decide what
gets checked in on the UCM project's integration branch (its "main"
branch). I perform the checkins, so I can police what gets "delivered".
(Of course, I'm expecting that the developer will have already successfully
"rebased" to the LATEST code set on the project's integration branch.
Thus, the work of the delivery activity consists of accepting trivial
merges.)
However, employing out-of-the-box UCM, any of San Jose's developers who are
working on the same UCM project can checkin to the project's San
Jose-mastered project-integration branch. When a San Jose developer begins
a "delivery" operation, he/she is not even offered the option to "post"
that delivery activity for completion by someone else (a designated
integrator). UCM nicely guides the developer through the merge from the
developer's development branch to the UCM project's integration branch.
The developer checks in as he/she pleases.
What's that?!! Developers deciding what gets checked into the project's
integration branch (its "main" branch)!!!. As a Release Administrator, I
don't like that.
One possible solution: Use MultiSite to set up a (virtual) site where
every project stream (and its associated branch) is mastered, but at which
no development streams are mastered. Thus, whenever a developer initiates
a "delivery" activity, UCM will automatically "post" that activity (the
merge) to someone at the site where the project stream is mastered. We
establish procedures for designating who, at the virtual site, can take up
those delivery activities.
I'm not necessarily going to implement this "solution". I'd be interested
in the thoughts of other CCIUGers.
Dan
Dan Rickhoff
Centigram Communications Corp.
91 East Tasman Drive
San Jose, CA 95134
Tele: 408 432-2764
Fax: 408 428-3827
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:23:23 EDT