So I'd like to settle on a final (or as final as anything is around here) list of Hg stoppers. According to the list (http://www.opensolaris.org/jive/servlet/JiveServlet/download/9-29382-113695-2725/hg-stoppers.html) we have:
132, 455, 498, 199, 274, 222, 226, 122, 269, 401, & 413 plus 522 from the thread below and possibly 576 That's 13 stoppers. Looking at the Mercurial bugtracker, the only one marked in testing is 498, so that's still 12 stoppers currently unfixed. What do you guys think is the likelihood of getting all of these fixed in time by mpm? Should we start investigating whether we can fix some of these ourselves? cheers, steve Mike Kupfer wrote: > Today was my day for dealing with the hg stoppers list. I'm not sure > I'll get to creating the shadow bugs (in bugs.grommit.com) today; but if > not, it should be tomorrow. > > I did want to follow up on the 3 issues that you mentioned as possible > additions to the stoppers list: > >> - Bringing over a change such as 6444783 (29301c5ea1f) should do something >> more sensible than complain (bringover of versioned file with same name as >> local unversioned file). > > I think we (you, Steve, and I) all agreed this wasn't a stopper. I > don't see an existing bug in the Mercurial BTS to cover this, and I > didn't file one. (I'm not convinced that renaming the child's file is > clearly superior than bailing out and making the user deal with it.) > >> - Bringing over a directory rename where the local directory contains >> unversioned files should do something other than give scary error >> messages, and a scarier (but apparently ignored) dirstate. > > I just filed issue 576 against Mercurial for this. AFAICT, the only > issue is the scary warning message when the child is updated. Can you > clarify what you meant by "a scarier (but apparently ignored) dirstate"? > > While I would like to see this fixed soon, I don't see it as a stopper. > >> - The polluted merge history bug stevel and I found. >> When merging with a TeamWare backout it is not uncommon for the file going >> back to its prior contents to confuse things such that the greatest common >> ancestor is miscalculated, and the file appears dirty on the 'child' side, >> forcing a merge. (Steve, did I get the details there right?) > > This is Mercurial issue 522, right? > > I'll mark this as a stopper for us for now. Once we get a better > understanding of how severe it is, we can decide whether to keep it on > the stopper list. (If the problem is likely to go away once everything > is in Mercurial, then it's not a stopper.) > > Sound okay? > > mike > _______________________________________________ > scm-migration-dev mailing list > scm-migration-dev at opensolaris.org > http://opensolaris.org/mailman/listinfo/scm-migration-dev -- stephen lau // stevel at sun.com | 650.786.0845 | http://whacked.net opensolaris // solaris kernel development
