I'm changing the subject, so as not to hijack Steve's original thread too badly. :)
Note also that this holds true for ON; I don't know how much of this applies to other consolidations. On Wed, Jun 07, 2006 at 05:56:06PM -0400, Bill Sommerfeld wrote: > with teamware, the biweekly builds are copied from the "trunk" > workspace, We call these biweekly-build workspaces the "snapshots". > and then if serious problems are encountered during testing, > specific fixes are cherry-picked from the trunk in order to make the > build usable both by itself and as a base for development. "Respins" > the final numbered build workspace is then published; longer-term > projects will tend to merge with the published biweekly build so they > can publish their own numbered project builds. This is primarily so that people who want to play with a particular project's deliverables can simply overlay the subset of ON which the project has changed (either through BFU or packages, or copying files), and expect the rest to work -- ZFS build 28 bits wouldn't have necessarily worked on top of the official build 30 bits, so testers would have installed build 28 and taken the ZFS build 28 bits. > in the extremely rare cases where this is not possible due to the nature > of the respin/cherry-picking, the biweekly build will he toxic for merge > purposes, We call that "diverging the snapshot". > and so two workspaces are published: one which is locked against > bringovers and is suitable only as a reference source, and a second one > which is "close", but non-toxic. Actually, at least for nevada, we haven't been publishing both. I think we've only diverged twice, and no one's complained. > I suspect that mercurial will make the merge-with-biweekly process a bit > different for child projects.. Indeed. In fact, it's going to be a different process for child workspaces to merge with any upstream changes, which, as I pointed out in my message on Friday, is going to make life difficult for nightly. :( Danek _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
