OK, I think I can summarize what (in my opinion) we should be doing. It's exactly what Rich is currently doing, with some added output.
I think I would like to see the following warnings: For each tag (both local and non-local) referring to a changeset that we're removing: "Removing [local] tag <tagname> and cset <changeset id> to which it refers" AND, where applicable, "Tag <tagname> has been implicitly reverted to refer to cset <changeset id>." I am NOT strongly attached to phrasing here. The first warning is pretty easily generated. The implicit reversion warning isn't terribly complex, as long as we keep track of the tag names from any lines we remove from .hgtags. Motivation: Rich is correct. This needs to be limited in scope to apply only to tagged changesets that we're stripping. And because this may be used in project-gate scenarios, where developers are allowed to push .hgtags, we need to handle both localtags and .hgtags. I would like to see the added output because I believe this generally indicates an unintended side effect of stripping the csets in question. More specifically: I believe that we should never see the implicit reversion messages, and the removal messages may well indicate a need to "transfer" a tag to point to the newly recommited cset. --Mark On Thu, 24 Apr 2008, Richard Lowe wrote: > Date: Thu, 24 Apr 2008 18:41:51 -0400 > From: Richard Lowe <richlowe at richlowe.net> > To: Dean Roehrich <Dean.Roehrich at Sun.COM> > Cc: Mark J. Nelson <Mark.J.Nelson at Sun.COM>, scm-migration-dev at > opensolaris.org > Subject: Re: Please review #356/#412 > > Dean Roehrich <Dean.Roehrich at sun.com> writes: > >> On Wed, Apr 23, 2008 at 04:51:40PM -0600, Mark J. Nelson wrote: >>>> #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? > > So, both you and mark say this. But I'm still totally puzzled as to > why. > > My goal with this was that we would stop leaving dangling tags (as you > saw), not that we should cover for a user who decided to create tags > that will remain valid. That's an entirely separate problem (and one > I would leave to the user, given we have no idea of their intent). > > You guys seem to want to cover for the case where we don't want > regular gatelings creating tags in the gate, and thus want to flush > anything tag shaped when they reci. I'd like to know why you think > that's right (as it molests their data for reasons other than "prevent > failure and scary warnings"). > > So far from this review, I've had that request above, twice. Mark > would like (I think?) the "wx reset" equivalent implemented, since he > would like the .hgtags reset available as a separate command. > > Beyond these things, are we happy with the code? I'm trying to get an > idea of where we're going with this, so I can get an idea of how long > it'll take to get there. > > -- Rich >
