"Mark J. Nelson" <Mark.J.Nelson at Sun.COM> writes: >>>> #356: >>>> >>>> http://mail.opensolaris.org/pipermail/scm-migration-dev/2008-April/001864.html > >> After the recommit, the .hgtags file should not show up in the recommited >> cset...rather than stripping .hgtags maybe you ought to just toss it out and >> not include it in the recommit? > > I'm glad Dean sent this, it helped clarify the way I think this should > happen. > > Like Dean said, I think that our recommit code should disallow > modification of .hgtags, possibly allowing an override (for use by gk, > since they're also allowed to push csets that include that file). > > This does NOT account for localtags. I'm OK with modifying localtags, > mostly as per Rich's webrev above, but I think it would be nice if > > - we defer the cleanup 'til after the recommit
It's currently done before the reci, since hgtags would be in the reci > - we cleanup all hanging localtags, not just the ones we strip If by hanging you mean, pointing off into nowhere, we currently cleanup any that *we* left hanging. I suppose I'm willing to try and remove any that point off to nowhere, but I'd rather not cover for problems that aren't our own. > - we provide this as a command that can be run outside or reci Assuming "outside of reci", I'm wondering why. > - we report on which local tags were deleted Ok > Something that still bothers me: the removal of a tag, without > overriding it to refer to cset 0, can expose an older definition of > that same tag. But in localtags, I don't think we should override with > cset 0, because that would forever elide .hgtags. So I think that, in > addition to reporting on which local tags we deleted, we should also > report on which of those, if any, are implicitly redefined by said > deletion. That may not be much fun, but I guess we can try. > Am I making this too difficult? You're covering cases I never intended the bug to, I tried to explain this to you yesterday on IRC. The case I was aiming to cover was that when you reci, we remove certain csets, those csets may have tags pointing to them. I intended to cover the case of *only* those tags (that point to node reci would remove), not other tags the user added, or any other form of user modification, error or otherwise. I could understand why you'd like that done, but I still think fooling around with something the user chose to do, and that would remain consistent (if not something we'd like) is wrong. 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). -- Rich
