>>> #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
        - we cleanup all hanging localtags, not just the ones we strip
        - we provide this as a command that can be run outside or reci
        - we report on which local tags were deleted

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.

Am I making this too difficult?

--Mark

Reply via email to