How to LOCK a Baseline in RTC components
Accepted answer
As Jeff Care already said, baselines are inherently locked because they are immutable. You cannot change the changesets they catalog, you cannot change their baseline ID (integer), and you cannot delete them from a component.
The only piece that is not locked by default are the baseline names, and those can be changed in the out-of-the-box templates. You can restrict that in the Project's Team Configuration Permissions ->
Comments
See My question was in UCM clearcase we have an option called Locking the Baseline.
Sreedhara thirthahalli,
RTC Baselines are -always- locked, you cannot modify or delete them once they are created, that is why we are saying they are immutable. Once a baseline is created, it is there permanently.
When a baseline is created for a component in RTC, it is assigned 4 pieces of data:
1. The baseline UUID (the unique identifier of the baseline.)
2. The baseline ID (human-readable unique integer of the baseline, like '48')
3. The baseline name (human-readable name of the baseline, like 'CORE.2_0')
4. The baseline description (human-readable description of the baseline, like "This baseline is for the CORE.2_0 release to customer X")
Once you create a baseline it is forever inserted into the component's baseline history. You cannot modify the changes it catalogs, you cannot delete it, the only thing you can modify for a baseline, out of the box, is the name and description, and as I posted above, even that can be locked down.
Sreedhara thirthahalli,
As I understand it, ClearCase UCM baselines can either be full or incremental baselines (or unlabeled technically.) In RTC all baselines are incremental baselines, they only catalog the new changesets since the last baseline.
In UCM you have a composite baseline which is a collection of these baselines across multiple components, in RTC a 'snapshot' is a collection of RTC baselines across multiple components.
When you perform a RTC build, typically as part of good CM practice you drop a RTC snapshot on the workspace that performed the build. This automatically creates, if needed, incremental locked baselines in each component that had new changes since the last baseline. None of these baselines can be deleted or modified, there is no additional locking needed, they already are locked.
If you need to rebuild, you delete the snapshot, rebuild, drop a new one, and thus it will re-create any new incremental baselines.
In ClearCase, whether or not a baseline is locked has no effect on the "rebase" operation (the rebase operation is affected by a lock on the stream being rebased). The only significant operation that is affected by a lock on a ClearCase baseline is that you cannot promote a baseline if it is locked. But just like RTC baselines, the configuration selected by ClearCase baselines cannot be changed after the baseline is created. I'm not sure what your scenario of taking a screen shot of a locked baseline is designed to achieve. A locked ClearCase baseline can be unlocked, so I do not see what relevance the fact that a baseline was locked at one time could have for a CAB board.
Now if you are asking whether it is possible to say in RTC "this baseline cannot be delivered to any streams", no, that is not something you can say. What you can do is say "only people with the following roles are allowed to deliver changes to this particular stream".
Comments
Jeff Care
Oct 10 '17, 11:36 a.m.Can you explain what you mean by "locking"? Baselines are immutable.
1 vote