Is there some "quick reference" for common issues for those of us
managing project gates with multiple children?
I want to convert my OSS project gate, but I'm concerned if I am missing
any important points that aren't in Stacey Marshall's doc. In
particular, I'm willing (happy!) to manually convert files, since we're
at a convenient point to do this, but I want to make sure that I'm aware
of any possible gotcha's with managing project gates.
Is there some document other than the red book that I can use for this?
(Note that I don't plan on doing unusual operations with mercurial,
other than possibly redelget equivalent and merges. I've not had to
grunge in TW files, for example.)
-- Garrett
Mark J. Nelson wrote:
>
> Standard apology for folks on lots of e-mail lists...
>
>
>
> If you're observant, you'll see that I can't count. Four weeks after
> I sent out an "eight weeks and counting" note, I'm sending a "three
> weeks and counting." Sorry for the error, but the "three" is an
> accurate number...
>
>
>
> Executive summary: This note constitutes a flag day for anyone
> planning to integrate changes into ON after build 96 closes: you must
> use Mercurial for any such work.
>
>
>
> The long-winded version:
>
> You've been hearing about this for a while now, so there shouldn't be
> any surprises here.
>
> The ON gate for build 96 will close at 23:00 Pacific Time on Monday,
> August 4.
>
> When it reopens for build 97, it will be managed using Mercurial. The
> timing for this gate opening is not yet known: it might be immediate,
> it might be overnight, or it might take a couple of days. But that's
> not really important right now: it will be managed using Mercurial.
>
> ------ Project Status, aka This Really Is Happening ------
>
> - The necessary changes to the SUNWonbld developer tools have been
> integrated to onnv-gate.
>
> - The necessary changes to ON gatekeeper tools are in progress.
>
> - The ON Nevada Gate will transition to Mercurial for build 97.
>
> ------ Documentation links, aka Learning Obligations ------
>
> Caveat: you might be able to get by on a teamware/mercurial cheat
> sheet for single-developer, small scope fixes. Anything involving a
> project gate, multiple developers, or complex operations requires
> additional learning.
>
> The good news: your work flow is not changing. Only the tools you use
> to get the job done.
>
> So it turns out teamware-to-mercurial cheat sheets are kind of like
> standards. The nice thing about that? It means there are lots of 'em
> to choose from.
>
> And it also turns out we (the scm migration project team) haven't gotten
> our documentation polished as much as we want. But here's some
> current pointers. It's either evolving in place, or I'll send updated
> pointers if/when we move or supplant the material in question.
>
> For Stacey Marshall's excellent Teamware-to-Mercurial reference,
> internal users can get the live version at
>
> http://braindump.uk/wiki/index.php/Teamware_to_Mercurial
>
> ...and external users can get a snapshot (I'm working on moving the
> live content outside, it just hasn't gotten completed yet) at:
>
>
> http://opensolaris.org/os/community/tools/scm/hg_teamware_transition/Teamware_to_Mercurial.pdf
>
>
>
>
> For some more general musings and links (including to the above), see
>
> http://www.opensolaris.org/os/community/tools/scm/hg_teamware_transition/
>
>
> ------ Developer Responsibilities, aka What You Need To Do NOW ------
>
> 1. Follow the tools flag day from last week:
>
> http://www.opensolaris.org/os/community/on/flag-days/pages/2008071001/
>
>
> 2. Unless you're integrating into snv_95 or snv_96, stop procrastinating.
> Switch to Mercurial. NOW.
>
> 3. If you're managing a project gate or need more sophisticated knowledge
> or Mercurial, then read the Mercurial book:
> http://hgbook.red-bean.com/
>
> ...this is particularly useful (required reading?) if you're
> accustomed to peeking under the hood (ie using SCCS or manipulating
> the nametable) in TeamWare. This tool is much different, and you
> should not expect to bypass it, or muck about with the way it stores
> files.
>
> 3. Really. Switch now. The wx2hg script is part of SUNWonbld; read the
> man page and follow it. Take a clone of the internal or external onnv
> gate:
>
> internal (open): /net/elpaso.eng/export/gate-hg
> internal (closed): /net/elpaso.eng/export/gate-hg/usr/closed
>
> external (open-only): ssh://anon at hg.opensolaris.org/hg/onnv/onnv-gate
>
> ...and go for it.
>
