Hi; I have a situation that is quite complicated.
Solaris (SunOS 5.9) cvs -version Concurrent Versions System (CVS) 1.10.8 (client/server) Copyright (c) 1989-1998 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors I hope that I am able to explain it sufficiently well so that I can obtain an answer from the gurus here that is useful. We have a trunk with many release branches. These release branches never (well, 0.001% of the time) merge back to the trunk. There might be one or two "ports" back to the trunk, but it is rare. Now each of these release branches is really considered a trunk where release branches are created and merged back into the trunk. So I will consider one of these main release branches to be a trunk for the purposes of this discussion. All cvs commit actions are strictly controlled by bug tracking (GNATS) verification (cvs trigger support in TCL) and code review (CodeStriker) verification (cvs trigger scripts in TCL), whatever the branch is. There are frequent requests for "throttle" release branches off of this trunk. These throttle release branches are even more tightly controlled cvs commits. Now everything that is allowed in to this throttle release branch is also allowed (forced actually by policy/procedure) to be placed in the trunk as well. The policy/procedure now is to verify that there is one and only one throttle release branch per trunk. We had a situation where we had two concurrent open throttle release branches for the trunk in question. Now I'm part of the SCM group that creates or locks down these throttle release branches. I think it is the developer leads who should have made certain that they want to move on to another throttle release branch that they request that the older throttle release branch be locked down first. But they did not do this and my team did not question this request. As a result, due lack of definitive communication within the developer team and betwen the developer team and the CM team, two concurrent open throttle branches exist for some time. Now when it comes time to release to QA from the throttle release branch, the throttle release branch is merged back in to the respective trunk. We did this with the second of the two throttle release branches. Later we find that there were two files that were not in the so-called trunk and were not in the second throttle branch, but were in the first throttle branch. One of the developer leads wants/demands that the CM team prove that these were the only two files that fell between the cracks, so to speak. I think that this is a developer team communication failure, not a CM team failure, but it doesn't matter. The developer lead thinks that the CM team has a failure in policy/procedure/practice and has broken support scripts for this task. The demand is to produce all cvs entries by name and cvs id that are in the first throttle release branch that are not in the second throttle release branch. I have tried the following command: cvs rdiff -s -r tag_1 -r tag_2 module The tags are done immediately the builds which are done immediately after the branch was merged (one build from the branch and the other build from the trunk). I have also tried: cvs rdiff -s -r branch_1 -r branch_2 module I have also tried : cvs rdiff -s -r branch_1 -r tag_2 module It was suggested that I try a cvs rdiff based on two timestamps, but that must be based on the sandbox containing the branch in question, no? So, I've got the lead developer literally banging my door down demanding answers that can be substantiated and verified independently. This person wants all builds of all branches of all releases of all products stopped until this is resolved Please advise me! Thanks, Ken Wolcott
