Folders in BikeCRs	Views in BikeCode	Folders in branch BikeCode/5.0	Folders in branch BikeCode/6.0
RootFolder ---Active ------5.0 ------6.0 ---Closed ------1.0 ------2.0 ------3.0	RootView ---5.0 ---6.0 ---Closed1.0 ---Closed2.0 ---Closed3.0	RootFolder ---change-requests ------5.0 ---src ---etc ...etc...	RootFolder ---change-requests ------6.0 ---src ---etc ...etc...

 

CR Entry and Last Build Tested
Case 1: A new CR is entered into the BikeCRs project. Of course the last build tested will default to the last build label created in the view. (A "Build" label is a View label with the "Use as build label" box checked.) Of course, we are in the CRs project and so the labels that we would use in our build cycle probably don't exist here. Those labels would be in the activity branch. I have thought about, but never undertaken, duplicating the build labels from the activity branch to the CRs project. It's a bit of extra work and extra load and for our shop, the benefit would be small. However, if your shop makes much use of the "last build" field then you might want to do so. The code sample below should help toward so doing. Case 2: A new CR is entered into an activity branch. Of course the last build tested will default to the last build label created in the view. Since we are in the activity branch, that will be a real most recent build label, which is "correct" in my view. Alas I haven't been able to get my QA team users into the idea of switching to the activity branch just to log a CR. They rightfully view that as too many clicks. Again, the last build tested field is not so critical to us. If it's not fixed it's still broken, and for our process that suffices.

CR Fixing and Addressed-In
Case 1: A CR is marked fixed in the BikeCRs project. I strongly discourage my team from doing this, and it's rarely done. The QA team is the primary users of the CR project and of course, the developers are the ones who usually fix and they are in the activity branch. Nonetheless, CRs do get marked fixed in the CRs view and as has been discussed before, they go to "Next Build" and stay there, even though a new build label is created in the activity view. This is because StarTeam's internal logic for "Next Build" is predicated on everything in one view, not having foreseen the sharing of CRs across views. Below is a code snippet of the "Fixed In Another View" program (FAIV) that I use to fix exactly this problem. When I run a build, I create a label and then run FAIV which finds all the "Next Build" CRs that still remain after the label's been created. Then, of course, FAIV applies the label to those CRs in the "Addressed In" field. This same code snippet could be adapted to handle the entry case where Last Build Tested is out of whack. Case 2: A CR is marked fixed in the activity branch. This is how things should happen and is the "happy path" case. These CRs get automatically "addressed" as one might expect. So, here's the FAIV code....

import com.starbase.starteam.*;

/**
* Title: FAIV
* Description: Handle Addressed In for fixed in other views
*
* parameters
* 0 label
* 1 project/view
* 2 admin passwd
* 3 other project/view
*/
public class FAIV {
public static void main(String[] myArgs) {
// splash
System.out.println("FAIV");
System.out.println("...find all CRs in " + myArgs[1] );
System.out.println("...that were addressed in "+myArgs[3]);
System.out.println("...and are addressed in Nextbuild");
System.out.println("...and set their AddressedInBuild");
System.out.println("...property to "+myArgs[0]);
// open folder: Octane/Octane/change-requests
Folder myFolder = StarTeamFinder.openFolder("Administrator:"+myArgs[2]+"@scm.fieldglass.com:49201/"+myArgs[1]+"/change-requests");
// get server and type
Server myServer = myFolder.getView().getServer();
Type myType = myServer.typeForName(myServer.getTypeNames().CHANGEREQUEST);
// find the label for the argument
Label valueToSet = null;
Label allLabels[] = myFolder.getView().getLabels();
for (int i=0;i /*less than*/ allLabels.length;i++) {
if (allLabels[i].getName().equals(myArgs[0])) {
valueToSet = allLabels[i];
System.out.println("Found label "+valueToSet.getName());
}
}
if (valueToSet == null) {
System.out.println("ERROR: Couldn't find label "+myArgs[0]);
}
View OtherView = StarTeamFinder.openView("Administrator:"+myArgs[2]+"@scm.fieldglass.com:49201/"+myArgs[3]);
int OtherViewID = OtherView.getID();
// get properties
Property propAIB = myType.propertyForName(myServer.getPropertyNames().CR_ADDRESSED_IN);
Property propAIV = myType.propertyForName(myServer.getPropertyNames().CR_ADDRESSED_IN_VIEW);
Property propNum = myType.propertyForName(myServer.getPropertyNames().CR_CHANGE_NUMBER);
// setup list managers
FolderListManager flm = new FolderListManager(myFolder.getView());
flm.includeFolders(myFolder, -1);
ItemListManager ilm = new ItemListManager(myType, flm);
// ilm.getItems(); //redundant because we getItems in the next line
System.out.println("Found a total of "+ilm.getItems().size()+" CRs");
// create a query for Addressed in Next Build and Addressed in view myArgs[3]
QueryPart qpAIB = new QueryPart(propAIB.getID(),
QueryPart.REL_EQUAL,
Label.NEXT_BUILD_ID
);
QueryPart qpAIV = new QueryPart(propAIV.getID(),
QueryPart.REL_EQUAL,
OtherViewID
);
QueryNode qn = new QueryNode(QueryNode.OP_AND);
qn.appendQueryPart(qpAIB);
qn.appendQueryPart(qpAIV);
QueryInfo qi = new QueryInfo(myType, false, "FAIV: temp query", qn);
// select items
Items targetItems = ilm.selectByQuery(qi);
System.out.println("Found "+targetItems.size()+" target CRs to update");
// and now run through the items, updating the AddressedInBuild property
for (int i=0;i /*less than*/ targetItems.size();i++) {
Item aItem = targetItems.getAt(i);
ChangeRequest aCR = (ChangeRequest)aItem;
aCR.setAddressedIn(valueToSet.getID());
aItem.update();
System.out.println("Updated CR "+aItem.getByProperty(propNum));
}
}
}

 TrackBack URI for this entry

Comments (2)

Subscribe to this comment's feed

dave: ...

thanks for the comments. the process shown in these posts is pretty much the one I use, and the many gotchas in the process are tiresome, but it does work pretty well. it sure would be a nice world if...
:)

1

report abuse

vote down

vote up

December 15, 2006
Votes: +0

anonymous: ...

Hi Dave,

You have obviously spent WAY too much time in StarTeam! :) Having used StarTeam since version 3.0, I can tell that you have really paid attention to all the details and designed a way to get shared CRs to make sense (as it were, and if you follow this process correctly and always). That said, I don't want to get off on a rant here but...

Having gone through all of this, do you find that people are actually willing and able to follow the processes and workarounds that need? Do you find yourself wanting to stab yourself in the eye with a hot poker?

Requirements don't branch. Nor do Tasks or Topics. They are what they are, and they have the status they have. Period.

So why do it for CRs? Is there ever a valid business case for having CRs share and branch? Isn't this just a very complex (albeit very thorough and well-crafted) workaround for a flawed system design (StarTeam) that is not suited to real world use cases? In my book, a CR has a life span of its own, and that doesn't include having "variants" or branches. Give me a CR that represents the defect or change being requested. When that CR is done, close it and move on.

In StarTeam you cannot query across multiple Projects, Views, etc., hence the need to share CRs. But sharing, branching, existing in a specific folder, etc. -- these shouldn't apply to a CR. It seems that putting these items into the same containers as files and drawing no distinction

Wouldn't it be a wonderful world if we could:
* Discontinue support for sharing and branching CRs
* Manage all CRs in a completely different container (not in a Project, View or Folder, but separate from all of them)
* Create a {1..*} relationship between CRs and Views so that the CR could be listed as related to a particular set of applications, components, releases, etc. This would make it work more like ClearQuest and MKS.
* Throw away the Datamart and give me real-time query support against the database!


There is so much more to say about this, but I had to say something because the fact that CRs share and branch has been a thorn in my side for way too long. Of course, Borland doesn't want to admit that it is a design flaw, because then they'd have the tough job of having to correct it while supporting their existing customers.

Of course, that's just my opinion, I could be wrong.

2

report abuse

vote down

vote up

December 05, 2006
Votes: +0