"Mark J. Nelson" <Mark.J.Nelson at Sun.COM> writes: >>>> What is the story regarding snapshot gates like the ones found in >>>> /net/onnv.sfbay/export/snapshot? Will there be a snapshot-hg directory >>>> similar to the gate/gate-hg dirs? >>>> >>>> >>> Haven't checked in a while, so my info might be stale - but at least >>> when I was there we tagged the revisions at which the gate's closed with >>> the build number, so you could do 'hg clone -r onnv_90' and get the >>> revision when the gate closed for onnv_90 >> >> This is largely a matter for the gatekeepers, I would advise them >> thusly: >> >> - Keep the tags, they're very very useful >> - Take snapshots in a separate workspace, if you want >> - Respins must be in a separate workspace, whether that's a snapshot >> from above, or one created for the respin (and thus only extant for >> respins) is up to them. > > I'm with Rich. > > I can't speak for the gatekeepers, but having been part of the core > team, I imagine I think in a similar fashion. > > They should continue to tag biweekly builds, and folks wanting to sync > can then use something like this: > > hg pull -r onnv_97 > > Whether or not the gk's keep a separate snapshot workspace is really > up to them, mostly for their convenience. I believe that it makes > sense to do so, and a divergent snapshot becomes a mercurial > repository with multiple heads. > > But I don't think regular developers should be using the snapshots the > way they currently do. > >> Whether they would do that is not our business. > > No, but we're kind of blazing the way, and our advice carries some weight. > >>> For respins/backouts that went into the gate, I used to maintain >>> respin/backout bundles here: >>> http://dlc.sun.com/osol/on/downloads/hg-build-snapshots/ >> >> That won't happen in that way (obviously). Whether they would even be >> published is also up to the gatekeepers in question. >> >> I very much doubt it, because I suspect nobody actually gives a crap >> about doing it. > > Backouts go into the main, linear branch. Everybody gets 'em, > everybody sees 'em. > > Respins are not an artifact of ongoing development: they're an > artifact of our biweekly build/delivery system. As such, I don't > expect people to care. The metadata that tells you what bugs or fixes > are part of a biweekly build is available, but beyond that, I don't > expect people to need clone/pull access to divergent (branched) > snapshot repositories. > > If a development team is affected by a hideous problem that caused a > respin, it would be much more worth their time to pull up to the > needed fix from the main branch and merge, than to deal with > divergence.
The divergence is far less of a pain for us than for TeamWare, once they have merged with the gate that has the formally divergent fix, they're still good. See onnv-scm's history, where I've diverged us at least twice to pick up fixes we very much needed when I didn't want the entire gate. It works out just fine. -- Rich
