James Carlson <james.d.carlson at sun.com> writes: > 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.
It will, but there's a bunch of other stuff necessary for that too, I've long had the impression that we *needed* experienced people trying this and yelling at us. You're experienced, now you just need to try them and yell. :) > 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. I've gathered that too (and have spoken to at least one person from each set you posited existed, and I don't even know that many people ON people on casual speaking terms...), my view thus far has been that there isn't much we can do about that beyond advise them on what is sensible to do based on their specific schedule and needs. > 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. We have small and small-ish projects on opensolaris.org, in mercurial already. From a list of ON based workspaces there were several in surprisingly active use (I was surprised, anyway). There were also some, of course, that were unused. The intel-* gates seemed to be in use, and possibly using at least some of these tools (I can't bring over more than a couple of them though), the tesla related gates were in use (and were using these tools several months ago, at least). Darren's zfs-crypto work was using some of these tools... Anyway, we do have people using these tools, it's unclear on which tools and whether they're encountering problems. The optimistic view is that we know they're in use, and nobody is reporting bugs or yelling, so they must all work. I'm not an optimist. > 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'll let Mike, and more importantly Dave and John respond to that. Not least because it's just growing my confusion regarding our current plans in that regard. > 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. For production use, I was actually thinking of implementing our own bringover lock to remove that, if necessary (just as general information) > - 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. I think double bridging like that is going to be problematic. We've seen with the unidirectional bridge that it's particularly complex, at least for a while, to catch all the corner cases that can really screw things up. I had hoped, when talking with Steve (Lau) about this that we could do something of the reverse to provide safety netting. The Hg gate would go live, but would (for a while) generate putback diffs and similar toys that a TeamWare gate could use to keep in sync. The latter would act as a fallback and be retired as appropriate (probably fairly quickly). Note that the latter is unidirectional in the other direction, rather than bi-directional with either side accepting changes. I think what you propose above could work, but I'm not immediately seeing benefit beyond safety netting. Our hope has been that the conversion tools TW->Hg would provide an adequate one-shot conversion (no history) for any workspace that wished for it. If a long-running project wished to stay in TeamWare after the gate had transitioned, they could, but they'd have to convert and do their final merge in Hg. (of course, if we were running something to keep TeamWare in-sync while Hg was the master, they'd only have to convert once pre-putback, then retest etc). I'm nervous about the concept of allowing TeamWare to survive longer than necessary, It makes me concerned it may survive indefinitely. -- Rich
