>>> 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.
--Mark
