James Carlson <james.d.carlson at Sun.COM> writes: > Mike Kupfer writes: >> 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. > > Getting that process started seems tricky to me. If you've read the > documentation and played around with the tools a bit, you really just > know the basics. You probably don't know what to do when things start > going strange, how to recover from real blunders, or just what the > "elements of style" might be. Even if the tutorials cover this.
That's true, but it's true in general. I don't think we're going to avoid that learning process. In general, I'd like to make things as clear as possible, and make sure people know that we (or other suitable people) are around to assist. > I think you'd learn more from the sweaty-palms exercise of putting > back to ON via Mercurial than you'd ever learn in a web of > my-feature-hg workspaces. > > We can run along with something like hg2wx, and I can agree with it as > it seems to be the group consensus, but I'm less certain that we'll do > much seeding. I'm not sure we will either, but I still don't see how that logic pans out. People are unlikely to actually care about this stuff until they have to, and I suspect would prefer it didn't happen (call me cynical...), the people most likely to sign on to try it out early in your scheme are the same people that most likely already use it. >> 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. > > OK. Since it seems that I'm interested (;-}), I guess I'll take some > time to look into it. If you use cdm's active list as the source of data, it's probably not that bad. If you do choose to do it that way, I'm willing to help, if I can. >> 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. > > That makes you one of the converted. I can't tell if that's a pun, or a mis-reading of the paragraph above. I'm going to assume the former and groan. >> 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. > > There's no such fear here. A lost lock means that the changes are not > committed, the transaction rolls back, and the user must resync and > try again. I haven't looked at your locking model in detail, but I do recall being concerned about the risk of a change partially integrating, when I read through it the first time. (it hitting a subsidiary workspace but never fully propagating through the rest) > It's not an instance of "breakage." I agree that if any of the gates > were in some sort of unstable state (where we weren't sure what was in > the gate), the right thing to do would be to disable putbacks and call > in a human ... or at least a gatekeeper. Which is a problem in itself, at this point the gate staff aren't really familiar with the Hg way of the world either (because they have no specific reason to be, yet). Our plan of record is to migrate SFW first, as has been said. I think a lot of the surrounding expertise will come out of that (and project gates). How best to spread that knowledge I'm not yet sure of. -- Rich
