Stephen Lau <stevel at sun.com> writes: > I talked to Mike Sullivan about migrating SFW before ON, and he is > pretty adamant (understandably so) about wanting our tools integrated > into ON first so that he doesn't have to install a private SUNWonbld > package, especially given SFW's developer's shared use between SFW & ON > workspaces and potentially shared build machines.
Makes sense, yes. > So basically the scenario he is envisioning is: > 1) we putback our changes making sure they still work for Teamware since > ON will still be on Teamware > (excepting the SCCS keyword cleanup, and possibly other changes) > 2) convert SFW to Mercurial > 3) convert ON to Mercurial later Well, that delays matters for SFW, but it's doable. > What do you guys think? It's not the answer I was hoping for, since I > was hoping SFW would provide some exposure/testing to the tools before > they went into ON; but I can understand Mike's concern. Honestly I > think if this *did* happen, it would just push back the migration of ON, > since I don't know that we'll finish up all our work by September to > integrate into ON anyway. I don't want migrating SFW to delay ON, however, several (varied) people have mentioned to me that something smaller than ON moving first would make them far less worried about this, SFW is the only real target that qualifies (since it's the only smaller-than-ON consolidation that's open, aiming for Hg, and ON-like). > On the plus side it does make sure that our tools are backwards > compatible (not that I think that's really an issue), and it will get us > additional tools testing as people will really start using the tools on > mercurial workspaces (since not everybody knows how to find our onnv-scm > SUNWonbld) > The obvious down side is that it presents a chicken and egg problem. It seems that beyond a handful of people, nobody is willing to try this stuff out until it integrates into ON, and we don't want to integrate into ON without a fair number of people having tried it out and seemed happy. -- Rich
