>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.
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.
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.
>>>>> "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.
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)
Jim> All of this leads to: I think we need a way to allow people to
Jim> commit changes to ON via Hg *before* the official conversion date.
Jim> (Another way to phrase this would be: we need both an Hg-start date
Jim> and a Teamware-end date, and the two should not be the same day.)
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?
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?
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.
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.
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.
We'll also need to handle renames.
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.
mike
