I might be missing something here, but here goes. If you make branches for each build, wouldn't you "close out" the branch after the build was pushed out the door? That is, merge the branch back into the trunk somehow, so that it no longer counts as a head? Probably you just merge it back and junk any changes on the branch as part of the merge. That leaves you with a good tag to represent the exact contents used for the build, but your main trunck is undisturbed by the merge.
So the confusion of multiple heads is really a temporary thing when you've got an active build going on, and even then there's only one extra open branch right? You'd still want the default-branch-to-update-to feature to avoid problems when a side-branch was active. I'm in a different consolidation, but this issue is pretty general for any team with regular builds. --chris Danek Duvall wrote:
Here's a question that's been floating in my head for a little bit, and I wanted to get y'all's opinions. As part of the ON biweekly build process, we "take a snapshot" of the gate. Currently, this means that we do a full bringover of the development gate into a new workspace which has a descriptive name (onnv_57, for instance) into a more-or-less well-known NFS location, and then pull build workspaces from those to generate the bits.
_______________________________________________ tools-discuss mailing list [email protected]
