Mike Kupfer writes:
> >From a technical point of view, I think your proposal for a dual-scm
> gate could work. On the other hand, given our chronic lack of staffing,
> I have to wonder if it's a good use of our time.
It's a good question, and one for which I don't have a good answer.
(Btw ... I seem to be unsubscribed to this list, and unable to
subscribe. The system won't respond to my requests, but allows me to
post. I'm not even sure where to turn for help with oddities like
this. :-<)
> We'll get some testing when SFW moves, though with fewer people and
> reduced likelihood of their having to do merges in Mercurial. So
> perhaps having some subset of ON developers doing putbacks through
> Mercurial would be a benefit. And having more people with Mercurial
> experience in the organization would definitely be a win.
That last part is something I think is extremely important.
> But as Rich mentioned in his response, the existing gate is complicated
> and somewhat fragile. Adding a bidirectional component seems certain to
> make that worse. And it's something we're going to throw away after
> (hopefully) no more than a few week's use. So it's not clear to me that
> the payback is worth the investment.
Yes, I agree that the benefits are only temporary and that it exposes
new risks -- particularly if we were to open it to "everybody" right
away rather than adding committers one at a time.
The risk that I see on the other side of this is that if we "go live"
with an hg gate without having provided some reasonable way for
project teams to try their hands at real hg-based integrations first,
we'll be faced with two problems:
- We'll have nearly zero experience in the organization in dealing
with the procedure. People seem to have a difficult time today
with teamware putback (often doing it from the wrong machine), and
adding a whole new tool change is likely to result in having our
group answering a lot of questions rather suddenly.
- We'll be providing existing project teams -- even those that start
on day T-1 -- with no reason to bother with Mercurial, because
(from their perspective) there's no guarantee they'd ever be able
to integrate from an hg-based workspace.
I'm expecting a really tough sales job here in getting people to
migrate over, and if we fail at that, the consequences will be pretty
grim.
It's a big change, and we're going to make mistakes, project teams are
going to make them, and the gatekeepers probably will as well. That
all argues (at least to me) in favor of finding incremental steps
where we can.
> >>>>> "Jim" == James Carlson <james.d.carlson at sun.com> writes:
>
> Jim> I think we'll do better if we offer a means for at least a few
> Jim> willing folks to convert early, and better still if we can offer an
> Jim> incentive (in the form of lower risk and maybe public kudos) for
> Jim> projects to do so.
>
> I don't know that we can offer much in the way of lower risk. Projects
> already can use Teamware until the last minute and then convert to
> Mercurial with wx2hg. That seems pretty low-risk to me.
I guess I'm expecting more ETOOHARD than you are. :->
> What I think we can offer are
>
> - public kudos
> - promises of increased level of support (compared to moving with the
> masses)
> - benefits inherent to using Mercurial (e.g., faster bringovers)
... but as a downside risk, those projects choosing to convert over
(the "early adopters") are now dependent on us meeting out schedule
for a full conversion of the gate. If we miss, then they're blocked
out of the gate for as long as we miss.
If I were a project team lead trying to hit something in the April to
(say) December 2008 time frame, I don't think I'd even consider that
option. As an arbitrary OpenSolaris project team lead, I have no
visibility into or responsibility for any problems the SCM team might
have.
Perhaps more significantly, my _manager_ has no responsibility there.
> Jim> I think this is doable, and I plan to put some time into working
> Jim> through the logistics. It seems like it should work something like
> Jim> this:
>
> If I understand your proposal, it would look like this (ignoring clone
> workspaces):
>
> +-----------+ +-----------+ +-----------+
> | onnv-gate |---------->| submission|----->| onnv-gate |
> | (TW) | | gate (hg) | | (hg) |
> +-----------+ +-----------+ +-----------+
> ^ ^ +-----------+ | ^ |
> | | | sync gate |<-+ | |
> | +-->| (TW) | | |
> | +-----------+ | |
> v | v
> +-----------+ | +-----------+
> | developer | +--------| developer |
> | workspace | | workspace |
> +-----------+ +-----------+
>
> Is that accurate?
Yes.
> Jim> . if the change is from the internal bridge, then just return
> Jim> success.
>
> I'm not sure how the hooks identify changes coming in from the TW side.
> Something that the TW->hg bridge puts into the environment?
It'd be pretty easy to identify by $HG_URL, I think. In a pinch, the
more general solution is to put a special keyword in the putback
comment itself.
> Jim> . a write lock is applied to the onnv-gate and an internal
> Jim> child gate is sync'd and locked. (Lock failure means
> Jim> conflict; hook fails.)
>
> The code to update the sync gate might be subtle. I don't think we
> want to just do a simple bringover, as that will be slow. If we update
> the sync gate via putback notifications from onnv-gate, I'd be worried
> about races. Another option might be to use Bonwick's "rp" script to
> restrict the file list for the bringover.
Syncing only the files involved in the putback makes sense to me.
Even if it were "slow," I think that'd be mostly fine. The idea is to
provide a viable path for those early adopters, not necessarily a
perfect one.
> Jim> . a timer is started; the next hook must run in N seconds
> Jim> (N=300?) or the write lock is removed.
>
> Automatic lock removal needs to be considered very carefully. We don't
> do with the current TW->hg bridge (locks must be removed manually). My
> experience so far with bridge failures is that requiring manual removal is
> a win.
There are two independent scripts that run, and I'm covering for the
case where the second script _never_ runs because the 'push' was
interrupted. The automatic lock removal doesn't look so difficult to
me -- you terminate your timer on the second script invocation and, if
you've already lost your lock (which should just never happen), you
fail out.
> Jim> . copy in the changes to the locked child, delget them, and
> Jim> run putback.
>
> The equivalent code in the TW->hg bridge does the copy (for existing
> files) by applying a patch. If gpatch produces any reject files (or,
> IIRC, if there is any fuzz applying the patch), the bridge bails out
> with an error. I like this because it helps catch situations where the
> TW and hg sides somehow got out of sync.
Not a bad idea.
> We'll also need to handle renames.
Yes. Those do look a bit odd in hg. :-<
> Jim> [1] I suggest April 1st, with not much basis other than that it's
> Jim> still in the future, it's aligned with Sun's fiscal calendar,
> Jim> and it seems like an appropriate day to switch gates.
>
> I'm not talking dates until we've finished the scheduling review. We've
> already had multiple iterations of picking a random date and not making
> it.
Understood. We still need to advertise a date well enough in the
future so that project teams can _plan_ around it. Announcing that
we're going to do the conversion in (say) one month wouldn't be nearly
as good as giving a date that's a couple of months out.
As for not making it, I think I'd rather see us be a little more
flexible about what gets delivered and when. Looking at the plans so
far, it seems that we're shooting for having zero regressions on day
one. That's admirable, but it's also true that we lived for many
years without fancy tools such as 'wx', and if we had to limp along
for a month or two with manual work-arounds for doing things like
collapsing deltas^Wchangesets because the extensions aren't fully
tested, I'd prefer that to slipping the date further and further out.
Point taken, though, about the risk involved in an backwards bridge.
I'll talk with the gatekeepers again once we have a schedule review.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
