Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I would not recommend locking the vob or the files:</p> <ul> <li>both options would lock everything (ie any modification in <em>any</em> branch) for all (or most) users.</li> <li>you need (from the <a href="http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/index.jsp?topic=/com.ibm.rational.clearcase.cc_ref.doc/topics/ct_lock.htm" rel="nofollow noreferrer"><code>cleartool lock</code> man page</a>) 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)</li> <li>the maintenance is too cumbersome for files (you need to maintain the list of files you want to lock)</li> </ul> <p>Locking the stream or at least the branch is still your best option.<br> It is one simple atomic operation target to lock the right environment.<br> Combined with the <code>-nusers</code> option, you can still authorized some users to do what they need (checkout/checkins)</p> <p>The OP comments:</p> <blockquote> <p>Actually I want to prevent all the users from delivering those sensitive files.<br> If I lock the stream for particular user it will not serve the purpose. It will stop them delivering other files too</p> </blockquote> <p>The <code>-nuser</code> option lock for <em>all</em> users <em>except</em> a few.<br> 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</p> <p>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)</p> <p>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:</p> <ul> <li>not locking the stream</li> <li>putting a baseline before final day</li> <li>tweaking your build script in order for it to: <ul> <li>use whatever version found on final day</li> <li><em>except</em> for those "sensitive files" where the script would fetch their baselined version (and not the LATEST version found on final day, because said LATEST version might have been changed by some final deliver).<br> See for instance "<a href="https://stackoverflow.com/questions/6042330/clearcase-command-to-export-an-element/6043443#6043443">Clearcase command to export an element</a>" or<br> "<a href="https://stackoverflow.com/a/177350/6309">In ClearCase, how can I view old version of a file in a static view, from the command line?</a>".</li> </ul></li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload