2

Once you label file versions in a release, ideally you want to protect that code from inadvertant removal (please read everything before commenting). It is too easy to delete the code.

I know I can lock the label but the file versions attached to the label don't get automatically locked (you would have to create a perl script to do that?). You can lock an element but not an element version. Furthermore, once you lock an element, you can't check it out!!!!! STUPID. This stops future development! All I want to do is protect the code I developed (without copying it elsewhere for archive). A repository should protect the code you develop.

Of course, there is the protect command but that doesn't work in snapshot / web views.

Again, ideally you would want to lock all the element-versions in a release but still be able to continue development. The lack of this feature seems to be a gross oversight.

Any ideas? (if you have any perl scripts, please post)

kevin zamora
  • 153
  • 1
  • 7

1 Answers1

1

It is too easy to delete the code.

It shouldn't be: the only way you will be removing that labelled version from a ClearCase VOB is through destructive commands like cleartool rmelem or cleartool rmver.

All you need to do is to have a (preop) trigger in place denying those commands for everybody (except a ClearCase admin).

Something along the lines of:

cleartool mktrtype -nc -all -ele -pre rmelem -nusers $nusers -exec \"$perl_cmd -e exit(1)\" NO_RMELEM\aim"

I would still recommend to lock the label anyway, in order to make sure it isn't moved to another version.
As in:

ct lock -nusers vobadm lbtype:FOO_LABEL@vob:/vobs/admin

But again, if rmver is denied, your (labelled) code is safe.

Actually, the OP was talking about rmname (the DEL) in ClearCase Explorer.

The fear is that if a file is deleted, and a label is moved, then one could ignore for a long time the deletion.

BUT a label should never be moved:

  • the label from a ClearCase UCM baseline is immutable (you cannot move it)
  • a label in base ClearCase should always be locked
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for your input. I found more information about triggers at http://www.ibm.com/developerworks/rational/library/4311.html#t1 There also seems to be some restrictions on usage:Restrictions Identities For each object processed, you must be one of the following: type owner (applies to –replace only), VOB owner (element trigger types), project VOB owner (UCM trigger types) or: •UNIX and Linux: root •ClearCase on Windows: member of the ClearCase administrators group – kevin zamora Aug 01 '13 at 04:14
  • @kevinzamora those limitations only apply for when you are *creating* the trigger *type*, and applying it on a Vob. It is not limiting the users who will be managed by that trigger. – VonC Aug 01 '13 at 04:42
  • Speaking of vobs, I am not an admin but I created a vob so I could experiment using the command you gave. However, when I try to execute, it complains "Unable to determine VOB for pathname" . I looked at the Ibm doc but couldn't make sense how to specify the vob. My Vob name is ProdTest and my web view path is c:\zamorak1_view_2\ProdTest . I looked at http://www.philforhumanity.com/ClearCase_Support_18.html and http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/index.jsp?topic=/com.ibm.rational.clearcase.cc_ref.doc/topics/ct_mktrtype.htm but still couldn't make anything work. – kevin zamora Aug 01 '13 at 16:40
  • @kevinzamora you need to add the vob to your trtype (trigger type) name: `cleartool mktrtype ... name@\avob` (Windows) or `cleartool mktrtype ... name@/vobs/avob` (Unix) – VonC Aug 01 '13 at 16:54
  • @kevinzamora if that doesn't work, please edit your question with the exact command *and* its error message (and the current working directory your are in) for me to debug. – VonC Aug 01 '13 at 16:54
  • (getting closer...it created reelem trigger) C:\Scripts>cleartool mktrtype -c "Trigger to avoid rmelem command" -element -all -preop rmelem -execwin "ccperl -e \"exit 1\"" -execunix "Perl -e \"exit 1\"" NO _RMELEM reelem@\ProdTest cleartool: Error: Unable to determine VOB for pathname ".". Created trigger type "reelem". – kevin zamora Aug 01 '13 at 17:04
  • @kevinzamora I believe you have two names here: `NO _RMELEM` and `reelem@\ProdTest`. so keep just one: `NO _RMELEM@\ProdTest` – VonC Aug 01 '13 at 17:08
  • Got it! It looks like I actually had 3 names "No", "_RMELEM", and "reelem" (reelem was misspelled). Great, onto testing it now :-) – kevin zamora Aug 01 '13 at 17:18
  • Results are mixed. I was able to successfully prevent removal of an element through the command line but not through the ClearCase Explorer/ ClearTeam Explorer. I really wanted to prevent removal through the GUI since everyone uses the GUI. – kevin zamora Aug 01 '13 at 19:38
  • @kevinzamora are you sure you are talking about the same removal? The GUI allows for `rmname`, not `rmver` or `rmelem`. See http://stackoverflow.com/a/17729901/6309. Considering the restrictions in place for `rmver` and `rname`, a regular user wouldn't have the right to do those operations anyway. – VonC Aug 01 '13 at 20:20
  • I will look at your link later tonight/tomorrow. But my GUI allows me to right click and select "open, delete, rename, checkout, show version tree, etc". When I select delete, it removes the element from my view. I won't be able to respond till late tonight or tomorrow. I really appreciate your interest and help :-) – kevin zamora Aug 01 '13 at 20:43
  • @kevinzamora that is `rmname`!!! Nothing to do with `rmelem`. You can easily restore a `rmname`. Not a `rmelem` (which removed the element completely from the Vob database). See http://stackoverflow.com/a/4634373/6309 – VonC Aug 01 '13 at 20:44
  • Yuk. This is a very disappointing implementation for their GUIs. The fact that I can restore is not the point (sigh). Prevention of any delete, rename, etc. is the goal.....So I guess I have to create triggers for rmname (delete) and rename as well. If you don't, files could be removed and go undetected for quite some time....and only a very experienced admin would know what to do. – kevin zamora Aug 02 '13 at 13:41
  • @kevinzamora no, this isn't an issue I have seen in 12 years of ClearCase administration: you can leave the `rmname` alone. Only `rmver` and `rmelem` are really dangerous. – VonC Aug 02 '13 at 13:43
  • My point is simply that if files/directories are deleted, and no-one is the wiser, who is to know what is the original and correct content? I may leave tomorrow after accidently deleting files (hiding files) some months ago. Then, a new person is hired and is told to make a "View" based on a released Label will not be aware that the Label "contents" have been altered. That is why I believe you need to make triggers on the delete/rename operations. Do you agree? – kevin zamora Aug 02 '13 at 14:07
  • @kevinzamora I garantee you: this is a non-issue. As long as you can see the version tree of the parent directory of the "deleted" file, you know you did what and when. If the label is set on a content with the right files, then you can delete any file you want, that label will still reference the right files. Unless you move the label, but you wouldn't do that, would you? At lest not with ClearCase UCM (the label from a baseline is immutable) – VonC Aug 02 '13 at 14:20
  • @kevinzamora a label should *never* be moved. If moved, then... http://www-01.ibm.com/support/docview.wss?uid=swg21500878 – VonC Aug 02 '13 at 14:21
  • @kevinzamora I have edited my answer to reflect my last point about label. – VonC Aug 02 '13 at 14:25
  • Ok, but I am still going to experiment with adding those triggers because "prevention is the best medicine". Also, the fact you can see a Version tree of what and when doesn't tell "why" it happened (and that would be confusing and take time to figure out. And nobody has enough time, right?). But maybe I will agree with you after I experiment some more. Have a great weekend! :-) – kevin zamora Aug 02 '13 at 14:38
  • @kevinzamora I cannot stress this out enough: this is not, repeat **not** a problem. Like not at all. – VonC Aug 02 '13 at 16:23