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. 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. > 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. > 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'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. 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. > 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. OK. -- 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
