It's all about the answers!

Ask a question

How to lock a baseline/snapshot and a build results

Andrea Toncelli (2749) | asked Sep 25 '14, 3:19 p.m.
edited Oct 10 '17, 1:10 p.m. by David Lafreniere (4.8k7)


 Not all the builds, snapshots and baselines are created equal.  
If I run an automation process, I have hundreds of builds during the week.  I would like to lock the build that I send once a week to the Quality team and with that build, the baseline and snapshot associated with it.  I noticed that all the build results can be deleted as well as the snapshots.  For the baselines I can rename them.  I like that functionality up to a point. I would like to mark one of them as 'released' (I am using here a Rational Synergy term). In Synergy I can release a baseline, at that point, NOBODY can touch, rename or delete that baseline and the version associated with that baseline (in RTC would be the baseline name) is locked, no other baselines can be created wit that that exact name.  
I do realize RTC is different, so.... how can I do something similar to that in RTC?

Same question applies to the stream in similar circumstances. At the end of my 'release' cycle I want to ship the product, so I need to lock the stream.  Everybody needs to be able to see it as a record but nobody should be able to add change sets to it, or rename it.

Accepted answer

permanent link
David Lafreniere (4.8k7) | answered Oct 10 '17, 1:09 p.m.

This post/question actually has a few questions in it. Geoffrey explained some of them, but I'll provide an 'answer' here as well, with a summary of what was already answered plus answers to other questions. Feel free to open up enhancement requests or RFEs for any behavior that is not present and you feel would be beneficial.

Note: These comments are as of RTC 6.0.5.

-Can I create a release from a build?
Yes. In the Eclipse RTC client, open up a build result, and select the "Create a release to associate with this build" in the "Associated Release" section in the 'Overview' tab. This will create a release object and associate it to the Build Result. This will also automatically un-check the 'Deletion allowed' checkbox as well so that the build result will not be automatically pruned or manually deleted . Note: Releases show up in the 'Releases' tab of the Project Area editor.

-Can I prevent the deletion of any build result?
In the Eclipse RTC client, open up a build result, and in the "General Information" section, un-check the "Deletion allowed" option. This will prevent the build result from being automatically pruned when more build results are created or from being manually deleted.

-Can I prevent the deletion of the build snapshot?
This can only be done by specifying what roles are allowed to delete 'any' snapshot in a Process Area. For example, you could change the owner of the snapshot to a stream which is contained in a process area (Project/Team Area) that has 'limited' ability to delete snapshots. Note: By default, all the snapshots associated with the build will be owned by the build workspace, and thus only the 'build user' should be able to delete the snapshots (so in general this restriction is probably good enough). But we tend to encourage moving the 'release snapshots' over to the 'stream' that represents the release. This makes the release snapshots easier to find.

-Can I prevent changing the snapshot/baselines?
(Reminder: a snapshot is just a set of baselines).
For the most part snapshots/baselines are immutable except for the ability to change the name and description (in which you would have to set up process permissions to dictate who can change this). Otherwise things like the ID of the snapshot/baseline cannot be changed, as well as the 'content' (such as the change set history, and the specific versions of the files).

-Can I lock a stream at the end of a release?
Creating a snapshot is one way to capture the state of a stream at the end of a release (although this generally would be done by a build as it creates a build snapshot). Another approach is to 'fork' the stream so that it forever is meant to 'sit' at that particular 'release', and use a different stream to represent the 'main' or 'head' stream.

If you do want to actually lock the stream for some reason, in RTC 6.0.2 we added a feature that lets you lock streams and components to prevent deliveries to the files in those streams or components. Stream and component locks work in a similar manner to file locks but apply to the entire stream or the entire component in a stream. When a stream or component is locked, any attempted deliveries by users who do not own the lock will fail with an appropriate error message. The user that holds the lock can still perform deliveries to the stream. A lock does not only prevent deliveries, it also prevents any operation that affects the files in the locked component or stream. For example, a component replace is also prevented.

-New & Noteworthy Mention:
-Stream/Component Locking Demo Video:
-SCM Command Line Client 'set lock' command:

Prior to 6.0.2, one approach might be to add a deliver advisor in the process spec to restrict deliveries to particular streams. By protecting your stream by particular roles or users, you can effectively lock the stream down.
"" describes how to protect individual components in a stream, the same approach can be used to lock down the entire stream.

Michael Valenta selected this answer as the correct answer

Andrea Toncelli commented Oct 11 '17, 10:07 a.m.

 I find it really interesting how this site is ..... "It's all about the answers!"

It only took 3 years to get an answer to some simple questions.
FYI: based on the quality of the product and the quality of the support (see above) I have moved on to better tools.
Best Regards

Geoffrey Clemm commented Oct 11 '17, 3:26 p.m.

 So an answer is given about 3 hours after the original question, and then 3 years later someone from the development team expends the effort to provide updates to the answer based on enhancements that have released since the original question, and somehow this is an indictment of the forum and the quality of support?

One other answer

permanent link
Geoffrey Clemm (30.1k33035) | answered Sep 25 '14, 5:29 p.m.
The content (set of versions) referenced by a baseline is immutable, so you do not have to be concerned about that being changed by anyone.  You currently cannot lock the name of a baseline, but through access control, you can restrict who can change it.  A baseline has a Unique ID, so to have a reliable reference to a baseline, store its ID in addition to its name.  

If you want an immutable reference to the state of a stream, just create a snapshot of that stream.   If you want to reproduce that state of the stream (including its history), just use that snapshot.

Andrea Toncelli commented Sep 26 '14, 9:38 a.m. | edited unknown

 Hi Geoffrey,

Thanks for the info.  
It sounds like I cannot lock a build result  and snapshot from being deleted or a baseline from being renamed beyond project permission. 
Would it be possible to request an enhancement to give the opportunity to "release/lock" some build results/baselines/snapshots?

Geoffrey Clemm commented Sep 26 '14, 12:41 p.m.

Yes, you are always welcome to submit an RFE.
You can use developerworks:

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.