I've looked through the work being done on this project, and I see a
lot of good stuff here. The work done so far has been based on making
Hg users just as successful with the new tools as with the old ones,
and that does seem important.
However, I have a concern with the coming flag day. We're going to
need a date[1] on which ON switches to accepting contributions only by
way of Hg. I think that flag day will be troublesome, no matter how
well we've prepared.
Sun's internal ON community is, for a lack of a better word,
"diverse," and on-going projects need to make some difficult choices
about when and if to convert to Hg. Some are going to jump on the new
tools as soon as possible in order to try them out, even if it means
missing a schedule deadline. Many will do nothing (no matter what we
tell them) until the flag day has passed and they're in deep water. A
few will insist that their project is important enough that it's the
flag day that must move.
We can pretend to be a lighthouse[2], but I think we'll do better if
we offer a means for at least a few willing folks to convert early,
and better still if we can offer an incentive (in the form of lower
risk and maybe public kudos) for projects to do so. These people can
serve both as eventual beta testers of the tools and as local experts
to help others who make the transition later.
All of this leads to: I think we need a way to allow people to commit
changes to ON via Hg *before* the official conversion date. (Another
way to phrase this would be: we need both an Hg-start date and a
Teamware-end date, and the two should not be the same day.)
I think this is doable, and I plan to put some time into working
through the logistics. It seems like it should work something like
this:
- We set up a separate Hg submission gate, as the known reader race
condition in 'pretxnchangegroup' could result in the inadvertent
escape of bad change sets.
- The prechangegroup hook on the submission gate does all of the
following before returning success:
. if the change is from the internal bridge, then just return
success.
. a write lock is applied to the onnv-gate and an internal
child gate is sync'd and locked. (Lock failure means
conflict; hook fails.)
. a timer is started; the next hook must run in N seconds
(N=300?) or the write lock is removed.
- The pretxnchangegroup hook on the submission gate does all of the
following before returning success:
. if the change is from the internal bridge, then just return
success.
. check for existing write lock (need to verify that it's the
same remote user here) and terminate the timer.
. check that there are no changes from the internal bridge
pending; abort if so.
. verify that the files in the locked child are identical
(sccs get -skp) to the files in the changeset before the
push'd change.
. copy in the changes to the locked child, delget them, and
run putback.
. release held locks.
- Putbacks via the existing bridge are sent to the submission gate
and then pulled from there to the main Hg copy. The existing
bridge is changed so that it ignores putbacks that arrive via the
inbound bridge.
Any comments/suggestions/alternatives welcome.
[1] I suggest April 1st, with not much basis other than that it's
still in the future, it's aligned with Sun's fiscal calendar, and
it seems like an appropriate day to switch gates.
[2] http://www.snopes.com/military/lighthouse.asp
--
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
