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.
In my experience (and that of another opensolaris person) the dirstate represents the not-really-versioned files from that directory as 'modified', when clearly they should be unversioned. It's not clear to me whether if committed, they would become versioned. That aspect is why I consider it a stopper (or close to it), webrev will show .make.state's for instance, and, as I said, it's possible commit would cause them to be versioned. >> - 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? Yes. > 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.) The impact on file content is negligible, the bigger problem is that once files become in that state they must be merged. onnv-scm contains quite a number at this point (any backout in the gate that we have merged, every file in that backout), as such when they're touched again I'm having to merge them (which is, obviously, mostly automatic because we never changed them), but has obvious potential for gross mis-merges. -- Rich
