Mike Kupfer wrote: > (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.
Yes, this was the original plan. I started asking in the summer of 2006 for volunteers who were willing to get up to speed on Mercurial and/or SVN early and be local experts for presentations, helping groups switch, answering questions, etc. My latest list is from follow-up email sent last July. I had 15 responses. Most people were willing to help test the tools and I believe everyone subscribed to tools-discuss (I'd have to doublecheck to be sure). Only 2 are subscribed to scm-migration-dev. Bonnie > > 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 > _______________________________________________ > scm-migration-dev mailing list > scm-migration-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/scm-migration-dev vi ~
