Dean Roehrich <Dean.Roehrich at sun.com> writes: > On Thu, Apr 24, 2008 at 04:59:10PM -0600, Mark J. Nelson wrote: >> >You're advocating dropping .hgtags on the floor (which I actually used >> >to do, and I decided that was wrong), and stripping everything >> >unreachable out of localtags. That is more far-reaching in effect >> >than what I'd been intending to cover, and you don't really justify >> >that in this mail (I can imagine justification for removing any tag >> >that's dangling in general, but not necessarily the rest). >> >> Dean, you actually hit this case in practice, right? Was that contrived, >> or the result of a normal workflow? > > Well, not contrived--I had no intention of ending up in that situation. I > bumbled my way into this one while testing the gate-side hooks. So yes, I'll > say I hit it in a normal workflow. It just seemed at that point where > recommit completes, I was stuck; recommit does not let me fix that cset, and > my gate-side hooks would not allow me to push it with the tag (yes, the tag > hook works). I would have to export, edit, strip, import; or one of the other > just-as-ugly methods.
Edit .hgtags back to as it was, recommit, .hgtags would be dropped from the active list, and be fully reset by the reci. (not pleasant, but it works) > How many people are comfortable using, or even explaining, the > 'revert' method for this kind of repair, eh? (Ah, quilt fold...a > fine, flexible, simple, recommit workflow, with no expectations of > hand-holding.) We have an RFE to implement 'wx reset', which resets a file to precisely as it was in the parent, which would cause recommit to drop it. It is yet to be implemented. > I satisfied with Rich's argument of doing as little meddling as > possible. Let that code go in. Someone's going to come back later > and ask for an option on recommit to drop .hgtags. I'd rather see us come to some kind of agreement as to what's correct. If I have to do this all over, I have to do it all over, I'd rather do it now than later, if I have to. -- Rich
