In RTC Source Control how do I lock all files associated to a work item's changesets?
Hello,
I am using RTC 4.0.3. My requirement is to be able to lock all the files that were modified by the changesets associated to a work item. I know that the lock feature can be done on a single file basis, but I'd like to do it massively.
Scenario: Let's say a defect impacts 50 files contained within 5 components. 5 developers each submit a changeset, 1 per component, and associate it to the defect. Before testing I want to make sure that those 50 files cannot be modified so I want to lock them. Is there a feature similar to locate change sets that allows me to select a work item (the defect), filter the associated changesets (5), and lock the files in the stream (50)?
Are there alternatives to accomplishing my goal?
Thank you and best regards,
Andrew
Accepted answer
I'm curious why it's necessary to lock the files for testing. The files in question probably rely on behaviour specified in other files, so unless you lock those dependences, your lock won't prevent behaviour change.
If your scenario is to pick a configuration of the stream and mark it as release quality, then it would make sense to verify a specific build or specific snapshot, since they don't change. If problems are found, then you can create a separate workspace/stream from the snapshot to fix the problems.
If you want to have a release candidate that can be iterated on (to fix bugs found in testing), then Ralph's suggestion of creating a separate 'stable' stream would make a lot of sense. RTC is intended to work in this manner: allowing you to put preconditions on streams or remove delivery permissions for untrusted users.
If your scenario is to pick a configuration of the stream and mark it as release quality, then it would make sense to verify a specific build or specific snapshot, since they don't change. If problems are found, then you can create a separate workspace/stream from the snapshot to fix the problems.
If you want to have a release candidate that can be iterated on (to fix bugs found in testing), then Ralph's suggestion of creating a separate 'stable' stream would make a lot of sense. RTC is intended to work in this manner: allowing you to put preconditions on streams or remove delivery permissions for untrusted users.
One other answer
Andrew, there is no built in feature to do that in RTC.
I have not seen this kind of request for years. I think the better option to proceed is to take a snapshot/baseline from the code, which is immutable, and then test on that. Developers can still work on new stuff while the testers have a stable code base to test on.
I have not seen this kind of request for years. I think the better option to proceed is to take a snapshot/baseline from the code, which is immutable, and then test on that. Developers can still work on new stuff while the testers have a stable code base to test on.
Comments
Another approach would be to create your own stable repository workspace and possibly an integration stream and accept the changes you want to your repository workspace. This helps to make sure the code you use does not change.
1 vote
It is possible to open the change sets in the change summary or explorer views, pick the individual changes, and lock those. It would involve a certain amount of shift-clicking, since you need to select the changes themselves, and not their parent folders.