Count of change sets and impact to efficiency
Situation: RTC 3.0.1.3 -- AIX 6.2, DB2 v9.7 FP6 (installed Sep 2, 2012, the fix pack, not this RTC repository)
Had to start an RTC application twice in 24h due to OOM exception after it had been running very well (June 15, 2012 restart). In the Active Services there were multitudes of 'compareWorkspace' activities having been in progress for a relatively long time (1/2 - 1h or more). I seem to recall a similar situation where "large" or "many" change sets had been recently delivered and all the individual developers were trying to get their workspaces in sync (accept). I noticed that one work item has recorded over 500 change sets, each with a single file. This seems to smack of Bad Form, but the question I have is: Are "large" or "many" change sets per work item to be avoided ? Am I errant in my thinking ? |
One answer
First of all, check if baselines are created frequently. The operation "compareWorkspace" has some dependency on baselines, when there are large changes between current and last baseline, the operation may takes a while.
From engineering perspective, "large" or "many" change sets per work item should be avoided. But I also think there may be some technical background why the single WI has so many change sets. Ideally, work item should be associated just one change set. After the deliver of the change set, and then some one realized he needs to modify it, it is tempted this guy want to associate original workitem. This may be bug in the code. But wait, why this guy deliver the code with bug ? So like this, from ideal engineering perspective, too many change sets means there is improvement point for better software development practice. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.