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. When we "respin a build", we make changes to the snapshot, and rebuild the build workspaces. The mercurial tree as it stands doesn't mirror this particularly well. Steve sticks a tag on in a changeset that immediately follows the last changeset of the build, but (to my knowledge, at least), doesn't follow any of the respin changes. What this means is that the build tags in the mercurial tree don't accurately represent the source that was used to build the corresponding SXCR build. Now, we could (and I think Steve and I had both assumed that we would) maintain distinct repositories for each snapshot, much like we do internally. But -- even internally -- it's always struck me as a bit of a waste. It's extra space on disk and archival media, it's an extra thing to remember where to go when looking for the snapshot, and it means that a single clone won't give you all the information about the snapshots -- if you decide you want to go look at a snapshot, you have to do a complete, second clone. So what about using mercurial branches? Rather than (or in addition to?) tagging the tree when a build closes, we branch at that point, giving the new branch a descriptive name (like "onnv_57"). Then respins are simply changesets added to the named branch, while normal development happens on ... the other branch. Now, because mercurial doesn't allow you to "hg update" to an unnamed branch (at least, not in any way I can find), the main development branch would need to be given a name. I've been using "main" in my test repos, but it really could be anything. (Indeed, a release branch is probably appropriate -- "onnv" right now -- when considering a repository lifecycle spanning multiple releases.) Do you think this would be generally worthwhile? Is the introduction of multiple heads too confusing? Would old ON developers detest the very idea of multiple heads? (Note that these heads would never be merged.) Would it be worthwhile trying to persuade the mercurial folks to formalize the handling of unnamed branches? Any other thoughts or comments? Danek _______________________________________________ tools-discuss mailing list [email protected]
