>>>>> #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
Right, but I think that ignoring .hgtags is more consistent with the rest of our work flow and tools, wherein we don't allow the user to push it anyway. >> - 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. I'm ambivalent about that aspect, I just see the "cleanup localtags" as something that can be cleanly separable from the recommit, since localtags isn't under revision control or part of any csets. >> - we provide this as a command that can be run outside or reci > > Assuming "outside of reci", I'm wondering why. Yes, "of." Per above. >> - 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. I don't think it's all that difficult. You can pretty easily keep a list of the tags that you delete from localtags, and it's not hard to do listtags after the recommit, and cross reference the tag names. ? >> 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. I understood, it just seems like we're bolting unnecessary complexity onto our recommit. The .hgtags cleanup (and maybe the localtags one, too) belongs in repair.strip(), and since we're not going to let folks push hgtags anyway, going out of our way to clean it up seems wrong. > 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. OK, I can see limiting the cleanup to nodes that we're actually deleting, but (again) I think that doing so pushes the logic into reci, when it belongs in strip(). > 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. So I agree, but it's kind of a lesser of two evils. I think it's evil to mess with stuff that's "not our problem," but also to include this logic in our code instead of hg. A compromise solution, in my mind, is to file a bug against hg, AND to provide standalone extensions to fill the gap 'til that bug is fixed. At a minimum, those extensions should handle localtags, and I'm OK either way with whether they fix up .hgtags or ignore it. Slight preferenc (I think I just waffled here) for fixing it up, because (I just realized) we DO want to allow project-gate style management wherein developers collapse deltas (relative to project gate), but wherein developers are also allowed to set .hgtags. > 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? This conversation is probably already too long and involved, and I'm not deeply offended by Rich's solution, only I hate putting this code here when it really, truly belongs in repair.strip(). --Mark
