I would not recommend locking the vob or the files:
- both options would lock everything (ie any modification in any branch) for all (or most) users.
- you need (from the
cleartool lock
man page) to be the type owner, VOB owner or root to be able to lock the files or a vob: if one of those sensitive files isn't created by you, the lock will fail (and the vob itself has likely been created by an admin)
- the maintenance is too cumbersome for files (you need to maintain the list of files you want to lock)
Locking the stream or at least the branch is still your best option.
It is one simple atomic operation target to lock the right environment.
Combined with the -nusers
option, you can still authorized some users to do what they need (checkout/checkins)
The OP comments:
Actually I want to prevent all the users from delivering those sensitive files.
If I lock the stream for particular user it will not serve the purpose. It will stop them delivering other files too
The -nuser
option lock for all users except a few.
The idea behind the integration stream is that is is not the user who make the deliver, but the stream integration owner who, at his/her own time, makes the deliver. If that stream is locked for everyone but the integrator, he/she can control the deliver
However, that puts the control of those sensitive file on the integrator (again, locking just those file would be a bad idea, and would make sure that any deliver fails, because of those locks)
If you still want them to deliver while being able to control that the build only use a certain version of those files, then I would rather recommend:
- not locking the stream
- putting a baseline before final day
- tweaking your build script in order for it to: