(Apologies in advance if I've written something nonsensical. I'm at home with a cold, and the neurons aren't all firing at 100%...)
>>>>> "Jim" == James Carlson <james.d.carlson at Sun.COM> writes: Jim> The risk that I see on the other side of this is that if we "go Jim> live" with an hg gate without having provided some reasonable way Jim> for project teams to try their hands at real hg-based integrations Jim> first, we'll be faced with two problems: Jim> - We'll have nearly zero experience in the organization in dealing Jim> with the procedure. People seem to have a difficult time today Jim> with teamware putback (often doing it from the wrong machine), and Jim> adding a whole new tool change is likely to result in having our Jim> group answering a lot of questions rather suddenly. Well, the original plan was to recruit a few people in each geo to help answer questions. I don't know the status of that; Bonnie might. Jim> - We'll be providing existing project teams -- even those that Jim> start on day T-1 -- with no reason to bother with Mercurial, Jim> because (from their perspective) there's no guarantee they'd ever Jim> be able to integrate from an hg-based workspace. I thought about providing a backwards bridge (hg2wx or some such thing) but haven't done anything about implementation. Jim> It's a big change, and we're going to make mistakes, project teams Jim> are going to make them, and the gatekeepers probably will as well. Jim> That all argues (at least to me) in favor of finding incremental Jim> steps where we can. I agree that incremental steps are good. I'm just not convinced that allowing both Teamware and Mercurial putbacks at the same time is the right incremental step. ;-) 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. Mike> I don't know that we can offer much in the way of lower risk. Mike> Projects already can use Teamware until the last minute and then Mike> convert to Mercurial with wx2hg. That seems pretty low-risk to me. Jim> I guess I'm expecting more ETOOHARD than you are. :-> Given a choice between doing development work in Mercurial and switching at the last minute using an automated script, I expect most project teams would find the 1st choice more of a risk, though I suppose I could be wrong. Jim> ... but as a downside risk, those projects choosing to convert over Jim> (the "early adopters") are now dependent on us meeting out schedule Jim> for a full conversion of the gate. If we miss, then they're Jim> blocked out of the gate for as long as we miss. Which is why we'd want to have hg2wx. Mike> The code to update the sync gate might be subtle. I don't think we Mike> want to just do a simple bringover, as that will be slow. If we Mike> update the sync gate via putback notifications from onnv-gate, I'd be Mike> worried about races. Another option might be to use Bonwick's "rp" Mike> script to restrict the file list for the bringover. Jim> Syncing only the files involved in the putback makes sense to me. Jim> Even if it were "slow," I think that'd be mostly fine. The idea is Jim> to provide a viable path for those early adopters, not necessarily Jim> a perfect one. That depends on how bad "slow" is. If it blocks other developers for more than a few minutes, we will be causing a lot of irritation. Mike> Automatic lock removal needs to be considered very carefully. [...] Jim> There are two independent scripts that run, and I'm covering for Jim> the case where the second script _never_ runs because the 'push' Jim> was interrupted. The automatic lock removal doesn't look so Jim> difficult to me -- you terminate your timer on the second script Jim> invocation and, if you've already lost your lock (which should just Jim> never happen), you fail out. I'll need to think about this some more when I'm less fuzzy-brained. What manual lock removal has meant for the current bridge is that when there's a problem, it doesn't get compounded by subsequent putbacks that pile on top of the broken one. That's a property I'd like to see preserved in any automated reverse bridge. Jim> As for not making it, I think I'd rather see us be a little more Jim> flexible about what gets delivered and when. Looking at the plans Jim> so far, it seems that we're shooting for having zero regressions on Jim> day one. Yes. Jim> That's admirable, but it's also true that we lived for many years Jim> without fancy tools such as 'wx', and if we had to limp along for a Jim> month or two with manual work-arounds for doing things like Jim> collapsing deltas^Wchangesets because the extensions aren't fully Jim> tested, I'd prefer that to slipping the date further and further Jim> out. I'm certainly willing to consider dropping various features on a case-by-case basis. But I'd want to take a close look at the tradeoffs. Saying we'll just resort to manual methods is too hand-wavey for me. mike
