Retrieve rmnamed elements and rmelem them

This question is not answered.

Posts: 39
Registered: Nov 24, 2004 09:18:18 AM Retrieve rmnamed elements and rmelem them
Posted: Nov 25, 2010 08:24:14 AM I need 2 answers.
1) Is there a quick way to retrieve the list of all elements removed (via rmname, NOT rmelem) from a VOB? I tried this command:
cleartool lshistory -fmt "%Nd#%En#%c\n" -r Luca_vob
In fact, I found in the output some lines like Uncataloged directory element "...", but the format does not satisfy me, as I would like to have, on a single line, the complete path of the removed element.
2) Provided that I succeeded in retrieving the removed elements list, how could I perform the rmelem of those elements? I mean, the problem is that they are no longer visible in the current configuration on the VOB, so I should create many views on past configurations (i.e. baselines).
Is there a quicker way to perform that?

Thanks in advance.

Posts: 416
Registered: Mar 15, 2005 04:40:07 AM Re: Retrieve rmnamed elements and rmelem them
Posted: Nov 25, 2010 09:29:23 AM   in response to: Lumart's post Lumart wrote:
> 1) I tried this command:
> cleartool lshistory -fmt "%Nd#%En#%c\n" -r Luca_vob

Several problems...
you recurse in your view, so you miss elements themselves not reachablethis recusion will miss the root directoryactually, you rely upon the default comments of the checkin events of directory objects...This comment is no guaranteed to be preserved, especially if the user gives a comment at checkin!
- it gets scrubbed for one thing;
- for an other, after you'll have removed the elements, the history of their parents won't change.

I doubt you are on a steady path, there.

Marc

Posts: 416
Registered: Mar 15, 2005 04:40:07 AM Re: Retrieve rmnamed elements and rmelem them
Posted: Nov 25, 2010 09:55:02 AM   in response to: 314's post Marc wrote:
> - actually, you rely upon the default comments of the checkin events of directory objects...

Sorry: I have to take this back. It is also in the comment of the rmname events, and it is at least harder to prevent it from getting there.

foo> ct co -nc .
Checked out "." from version "/main/mg/16".
foo> ct rm -c 'aaa bbb' a.c d
Removed "a.c".
Removed "d".
foo> ct ci -c 'foo bar' .
Checked in "." version "/main/mg/20".
foo> ct lshis -fmt "%o %Nc\n" -minor -since today -dir .
checkin foo bar
rmname Uncataloged directory element "d".
aaa bbb
rmname Uncataloged file element "a.c".
aaa bbb

All in all, you get something with:

ct lshis -a -fmt "%o %n %Nc\n" -minor -since 14:45 | egrep ^rmname

At least this doesn't depend on your view, and cannot be altered by the user comments.
The next this for your 2nd question would be to edit this into an element path, and to use it to get the oid (des -fmt %On). This, you could rmelem... assuming you master it, and got rid of the other checks (labels, locks, hyperlinks,...)

Some job for Perl.

Marc

Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

Popular tags shows the top tags for this particular type of content or application that you're viewing.

My tags shows your tags for this particular type of content or application that you're viewing.

Use the search field to find all types of content in My developerWorks with that tag. Use the slider bar to see more or fewer tags. Popular tags shows the top tags for this particular type of content or application that you're viewing. My tags shows your tags for this particular type of content or application that you're viewing.MoreLess 

View the original article here