we have a quite complex structure in our projects in Source Integrity. And sometimes our users are doing checkpoints with label, and then they realise that the label is wrong. And as you know, deleting a projectlabel doesnt work recursive (hmpf!). So we wanted to do this with a script via commandline. For this we want to know which subprojects are child-projects from this point in our structure where the label was set and (important) which of them are shares. If we look at it like this:
si viewproject --project=<name of the subproject which was checkpointed> -Y
then we get a text, in which the structure is shown by the numbers of spaces in front of each line (this is a very special idea i have to say). But even worse: this isnt very reliable (we filed this already as a bug to PTC-support), because sometimes it doesnt count correctly (there are not the right numbers of space-chars).
If we use the parameter --xmlapi we get a xml-structur, but i didnt found any information how the subproject-structure is mapped into this xml? All subprojects are laying parallel? And if i wanted to look which subproject is a child of another, i have to parse the attribute-entries?
An example. This is the output of "si viewproject --project=/Spielwiese/Test_NX2/test2/project.pj -Y" :
index.html.dk archived 1.1
index.html.ee archived 1.1
index.html.el archived 1.1
index.html archived 1.1
index.html.ca archived 1.1
I can see that "share_test1" is a share and "test1_1" is a child of it.
The output in xml with "si viewproject --project=/Spielwiese/Test_NX2/test2/project.pj -R --xmlapi" is attached to this posting.
In this xml-output i can see, in one workitem-element that share_test1 is a shared-subproject. The next element of type "Workitem" is test1_1, but it is shown as subproject. But this workitem-element is parallel to share_test1 and also to test2_1_1. How can i see which workitem is a childproject from another?
could you tell me some details related to the "indentation" bug mentioned by you (client version, repository type). We have implemented (in MKS 2009 SP6) a custom script for delete project label recursive by using indented output of si viewproject command, but we didn't observed strange behavior so far.
Where i can find details about this bug on PTC site ?
we're using Integrity 10.2. What do you mean with "Repository Type"? What kind of database we're using? Oracle 11. And unfortunately i didnt now which case- or incident-number is given by the PTC-Support for this bug, because i didnt have direct access to the PTC-Support.
The problem only apears if such a script with the viewsubproject-command is used many times very fast (nearly at the same time) from one client. We can reproduce it in this way:
3 different command CMD-windows, in each commandline the same command "si viewproject...", and all 3 commands "released" at the same time. The output from these commands are piped into textfiles, and very often the 3 textfiles are different. We have a 50/50 cance to get different outputs...
Our IT-department and the PTC-Support are trying to find the cause of this problem since two months.
kind regards, Jens
Hi Jens, thanks for info so far.
Currently we are using MKS Integrity 2009 and we can not use XML output in this case. So we are forced to use CLI with text format output. For me is important to know if you observed this strange behavior by using "si viewproject" command with --fields=indent,name,type --recurse arguments.
If you observed strange behavior also for "indent" argument usage, we will be forced to develop a custom recursive method for create the complete "folder" structure of a root project and his subprojects, based on "si viewproject" calls without indent and recurse features.
Related to "Repository type" , I want to know if you have source repository as db-backend or RCS style.
@Matthias: Do you think that JAVA API usage with MKS Integrity 2009 will absolve us on this issue?
YES I do think that using the API will definitely help you on that issue.
As you work directly on Objects you can eliminate a lot of parsing an formatting problems.
I started using the API with MKS 2007 , 2009 and currently we are on 10.2,
The only problem with the API is, that it does not cover all CLI commands (e.g. in the admin area) which limits the possibibilities a bit, but for Source it just fine.
if you take a look at your XML Output, there is several information available if you know how to "read" it:
1. there is no such thing a "indent" in the XML, all information is "inside" the workitems
2. in the output each part of project content (sub-project or member) is a workitem object (this reflects the Java API) and it attributes define the details (e.g. modelType="si.Member" or modelType="si.Subproject").
3. depending on the modelType you have different Fields belonging to the workitem. e.g.
should be available for all modeltypes.
The structure you see in the CLI output is exactly matched in you XML file, at least as far as I can check it.
And as you know, deleting a projectlabel doesnt work recursive (hmpf!). So we wanted to do this with a script via commandline. For this we want to know which subprojects are child-projects from this point in our structure where the label was set and (important) which of them are shares.
IMHO you should try to solve this via a small Java Application instead of a CLI-script, as the Java API allows you to handle the workitem objects directly e.g. via iterators and gives you more flexibilty and control for you tooling (and it performs much better).
thanks for your answer.
To your points 2 and 3: When i get a workitem with ModelType "shared subproject" and i want to know which workitems are childs from this shared-subproject i have to parse the string out of the tokenvalue to look if this string is a part of the childs tokenvalue. So it seems that the xml-output has only two advantages over the text-output: it holds the complete projectpath and ist seems not to be buggy.
Your second hint is really good, but i'm not a Java-Coder
kind regards, Jens
regarding the structure inside the XML:
each SubProject Workitem has attributes that hold the "structure" of this subproject
|id="#/Spielwiese#Test_NX2/test2/test2_1/share_test1#test1_1"||the config path to the current Workitem's project|
|parentID="#/Spielwiese#Test_NX2/test2/test2_1/share_test1"||the config path to the parent project of the current Workitem's project|
|the flat path to the current Workitem's project, as your would see it in the CLI or GUI|
As the output is a valid XML document you can use any language that can handle XML documents (C#, VB) to traverse or search the output in any direction you like by using XPATH.