Re: Direct Queries to CC Database

Replies: 9 - Pages: 1 - Last Post: Nov 18, 2010 5:14 PM Last Post By: Mark_at_Softwar... Threads: [ Previous | Next ]
Posts: 8
Registered: Oct 13, 2006 04:15:41 PM Direct Queries to CC Database
Posted: Nov 16, 2010 03:08:02 PM It may be easiest to just give an example. Suppose I want a list of all files (elements) whose basename is foo.c. "basename" is the last part of a path. So with a element on path /a/b/c/d/foo.c, the basename is foo.c.

I know about the "find" command (cleartool find . -name foo.c -print) but that is doing a linear search. There should be a way that I can do something like "select path where path like '%/foo.c'" in SQL terms.

I have many other questions after this one but this will get me started.

Thank you for your help
Perry

Posts: 686
Registered: Jun 25, 2007 04:53:38 PM Re: Direct Queries to CC Database
Posted: Nov 16, 2010 05:20:23 PM   in response to: pedz's post You can use an asterisk as a wildcard in the name:cleartool find -all -name "*foo.c" -print

You can also use the asterisk on both ends of the name to find substrings:cleartool find -all -name "*foo*" -print

-Jeff Ng

Posts: 885
Registered: Jun 09, 2005 09:06:53 PM Re: Direct Queries to CC Database
Posted: Nov 16, 2010 05:40:20 PM   in response to: pedz's post if you use -all, it will search independently of the config spec and also use internal indexes if available. That works up to a certain number of hits and ccan actually be somewhat fast. It depends on exactly what you are searching for.
You can use any sql because the CC DB isn't sql. It is called RAIMA and there is no user accessible interface except cleartool commands. They tried to use a relational DB and the performance was really bad. So RAIMA its is and will be.

Martina
Don't Postpone Joy - Have Fun

ReleaseTEAM Inc
http://www.releaseteam.com
IBM Rational Certified Consultants
IBM Business Partner

Posts: 8
Registered: Oct 13, 2006 04:15:41 PM Re: Direct Queries to CC Database
Posted: Nov 17, 2010 05:06:19 PM   in response to: martina's post time cleartool find -all -name foo.c -print

took 32 minutes to complete. :-(

Plus, I'm pretty sure it is searching only a small fraction of all the files. If I go up a directory, the find does not work. And in that directory, there are probably 20 sub directories. I think the find above is searching just one of the 20+ sub directories because that is where I started the find. Doing things like find * or find ./* did not work. But, its rather moot. CMVC could do the query over the same files in a few seconds and give me tons of more information in one query like tying changes to defects, etc.

It is fine if I can't do SQL but there must be some way to dig out the information that I'm looking for. So far, all the cleartool commands produce verbose texty stuff which has the data but with a lot of verbose text around it. I'm needing just the data.

Posts: 686
Registered: Jun 25, 2007 04:53:38 PM Re: Direct Queries to CC Database
Posted: Nov 17, 2010 05:36:55 PM   in response to: pedz's post You wrote: cleartool find -all -name foo.c -print

The "-all" option expands the search to the entire VOB that you are currently in. By default, ALL visible and invisible elements are searched, but there are options (-visible | -nvisible) to constrain the search. If you want to search all VOBs, use the "-avobs" option which will search all VOBs mounted on the host you execute the command on.

If the find command doesn't work one directory up, then you probably are not in a VOB anymore (multi-part VOB tag names).

-Jeff Ng

Posts: 8
Registered: Oct 13, 2006 04:15:41 PM Re: Direct Queries to CC Database
Posted: Nov 17, 2010 06:02:53 PM   in response to: jeff98air's post My point about find is it isn't going to work for me. It is way too slow.

There has to be another way to do this. Nothing could be this broken.

As a more practical question: how do I find the list of files that belong to a component? Does CC even have the concept of components? Some way to group files into sets that are managed by one team?

Posts: 474
Registered: Apr 08, 2008 11:40:52 PM Re: Direct Queries to CC Database
Posted: Nov 17, 2010 06:21:08 PM   in response to: pedz's post Lets step back a bit here - you need to tell us what your requirement is in context. What is the problem you are trying to solve?

It seems unlikely to me that you are going to frequently have to scour your entire source tree looking for foo.c (or whatever). More than likely there is a different way to solve whatever the underlying requirement is.

Posts: 201
Registered: Jan 15, 2005 05:15:03 PM Re: Direct Queries to CC Database
Posted: Nov 18, 2010 02:37:08 AM   in response to: pedz's post This question seems to me asked from a Subversion user that by default enquiries the database directly ---> "select path where path like '%/foo.c'"
scary way to work in Sofware Configuration Management

1- there is no need to use cleartool find unless extract data from all branches
2- when the view is mapped, default windows M: driver and Linux/Unix the stgloc set by the admin

Just use dir foo. /s* in Windows and ll -R | grep foo in Linux/Unix . . . . job done

But as someone has already asked, what is the purpose of you question, more important what is your aim?

Posts: 8
Registered: Oct 13, 2006 04:15:41 PM Re: Direct Queries to CC Database
Posted: Nov 18, 2010 12:33:01 PM   in response to: Anthony Coluzzi's post My initial objective is to "port" two CMVC scripts. I believe if I can do that, then I'll be on my way.

One of them queries CMVC and reports back, for all files like foo.c all the changes and all the defects that are associated with the changes for all releases for that file. I'd be somewhat content if it was only one particular file. So: All the changes, for all releases (what CC calls areas), tied back to Defect numbers. The report gives me the from and to sccs id strings. There is also a similar report that gives me all the changes for all the files for a particular component (for all releases). These reports take only seconds to run. We (support) do them rather often. I call those scripts Prs and Prs-comp.

The opposite direction is a script called Changes. It is similar to a CC script we have called ChangeRecord but the difference is that Changes goes across releases as well where as ChangeRecord requires a specific "area". So, Changes takes a Defect and reports back all the files for all releases changed by that defect. It too gives me the from (previous) sccs id string and the new sccs id string.

I get that the sccs id strings are different in CC/CQ but the purpose is the same. If we are talking to a customer and them to do a "what blahblah" to get the list of source files used to create that version of blahblah, we need to be able to quickly map that back to a defect and understand where that defect fits in in the stream of changes made for blahblah or for that component.

A typical support person in our team is supporting over a million lines of code. That is just the networking code, its drivers, and various other bits and pieces. There are probably a couple dozen such other teams supporting almost the same amount of code. Even knowing just the paths to the files is a challenge.

Posts: 474
Registered: Apr 08, 2008 11:40:52 PM Re: Direct Queries to CC Database
Posted: Nov 18, 2010 05:14:36 PM   in response to: pedz's post As I guessed you might need to try a different approach...

For a start - if you were using ClearCase's UCM instead of vanilla ClearCase I think at least some of those features would be available straight out of the box. However I gather you are not doing that.

It isn't quite clear if you are using ClearQuest as well as ClearCase but you must be using something to track change requests and linking that information to ClearCase. Its hard answer without knowing this.

For some more generic approaches... In ClearCase you typically label the versions of everything that are part of a release.
So for example one of the ones you mentioned - "get the list of source files used to create that version..." (I assume "version" in this context is a release of the deployed product). You would do a find by the label. There are several ways to do this (find command of course is one). In this scenario (searching by label) I think you would find "find" is much faster.

It also means you can just get a view of the code as at any release quickly... if you labelled everything as REL3.1 just create a view and set the config spec to:element * REL3.1
If it is a dynamic view you will then be looking at the entire source tree as at that release immediately.

Find can be used to identify all the versions of files that changed between two labelled releases. This is a bit more complex because it needs three find queries to cover the changes, adds, and deletes.

For your defect related identifier questions we'd need to know how you are connecting code to defects.

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