On Wed, Jun 07, 2006 at 05:56:46PM -0400, Richard Lowe wrote: > To expand on this based on what I just learned. Respins don't move the build > further along the history, the 'fixing' change is cherry-picked into the > build. > This means we can't just tag the new change as bN and bNa, as there's no > guarantee all preceding changes were part of that build.
Correct. > Making use of multiple heads in the same repository tends to confuse things > greatly. I also suspect that you can't pull -u when the incoming changes > introduce multiple heads (I'm not sure if this is the case when both new > heads > come from the remote, however). Certainly this is something we need to take a look at. If it's that painful, then we'll have to use separate repos for each build. > I'd certainly tag the build closure, but given the above, I can't think of a > way to deal with respun builds (well, ok, ceasing cherry-picking the fixing > change into the build, and taking the history up to that point, but I'm > assuming that's not tolerable). No, it's not. We have to have the ability to cherry-pick for respins. We can't take everything up to the change we need because major projects could have integrated in the meantime, and we can't re-test (and it's possible that such projects are actually cross-consolidation, and all such testing was in the works for the next build, and can't be rushed ahead two weeks). We also have to be able to do respins, because sometimes the problems they fix would truly cause a build to be DOA, and we want to avoid that as much as possible. Mercurial basically makes the difference between a normal respin and a divergent respin go away, but in the wrong direction, unless we can make the branching work for us. Of course, divergence will be a problem regardless, if any file is changed in a different way between one branch and the trunk. > Is the tagging of respins really such an issue? As I understand the above, > they > serve for no other purpose than to put a non-toxic set of packages into the > WOS, I can't (currently) come up with a situation where I would want that > exact > source, rather than a similar point along the gate's history (if I wanted the > fixing change, I'd take the gate after that change...) Having the sources available for a given build is required for reproducability. While we only archive long-term the sources for the final builds for any release, during the release the individual builds are useful for testing purposes. Of course, we can always do this the way we always have, with separate repositories. The question simply was whether it's meaningful to tag a snapshot "branch" when respins are a fact of life. The upsides I see would be saving disk space (something we could do almost as well with zfs if we can't with hg), saving directory namespace (if we care), and being able to publish the respins easily. I don't know if any of that would be worth the cost, but then I don't know exactly what the cost is, anyway. Danek _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
