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
