tags:

views:

157

answers:

2

Is it possible in clearcase to checkout a file for modification such that it is impossible to check it back in? I’m going to be hacking some files on a private branch, only some of which I want to ever check in. I want to eliminate the possibility of accidentally checking in unwanted changes. (I know we can write a trigger to check for magic keywords in the checkout comment; I'm look for something built-in to CC.)

A: 

I don't know about the administration. From a user standpoint, you could have 2 views. In one view, checkout the files you don't want to check in. In the other view (your view), check them out unreserved. Then, if you try to check them in, you'll get an error because they're checked out to the other view.

Dave
This would block other developers from checking in the files as they do their work. I just want to make sure *I* don't, because they not "mine", and I'm only hacking them to help me torture-test my new code.
Kevin Little
+3  A: 

"Hacking some files" is spelled in ClearCase lingo: hijacked files in a snapshot view.

All you have to do is to:

  • lock those files (except for the few developers you know are likely to checkout/checkin the files: cleartool lock -nusers userA,userB,... aFile)
  • create a snapshot view
  • change the read/write right (at the OS level, nothing to do with ClearCase here)
  • modify them directly (without checkout them first, hence the "hijacked" state)

The OP Kevin Little adds in the comment:

Alas, we only use dynamic views

Easy enough:

"Hacking some files" is also spelled in ClearCase lingo: eclipsed files in a dynamic view.

All you have to do is to:

  • lock those files (except for the few developers you know are likely to checkout/checkin the files: cleartool lock -nusers userA,userB,... aFile)
  • create a dynamic view
  • copy the files you need to modify as aFile.tmp
  • modify the config spec to not select them
  • copy them back to their original name (they became "eclipsed" as their private version override their official versioned counterpart)
  • remove the "none" selection rules from the config spec
  • modify them directly

To not select them, add to the config spec (ct edcs) before the other rules:

element /a/path/to/aFile1 -none
element /a/path/to/aFile2 -none
...

To restore them, all you have to do is move or remove those files.
They will be dynamically be replaced by their original and still versioned element.

VonC
Yes, I can see how this would work if we used snapshot views. Alas, we only use dynamic views. :( Thanks for the info; you obviously know CC quite well!
Kevin Little