Too many tags after converting CVS repo

[Matt Mackall]

On Mon, 2009-01-19 at 17:09 -0500, Greg Ward wrote:
> Hi all -- I'm playing around with my first experimental "hg convert" run
> on our large-ish CVS repository.  (Specifically: 8 years of history,
> ~17000 files in a trunk checkout, ~28000 files total, ~106000
> changesets.)  Happily, "hg convert" chugs through the whole darn thing
> without blowing up or creating garbage.  That's a good start!
> 
> But one of the quirks of our CVS workflow is a completely ludicrous
> number of tags to workaround CVS' merging deficiencies: every time we
> fix a bug, we bracket the checkin with a pair of tags.  Repeat for each
> merge.  So if a bug is fixed on branch 3.1 and merged to branches 3.2,
> 3.3, and trunk, we create 8 tags.  Over the years, that adds up: my
> brand-new .hgtags file has ~108000 tags, of which ~62000 are tags that
> wrap bugfix commits.
> 
> One side effect of having ~108000 tags is that it takes 7 sec to run "hg
> tip", because Mercurial needs to read through the enormous .hgtags file
> to see what tags apply to the tip changeset.  Ugh.  (I imagine Mercurial
> was not designed to have tens of thousands of tags, so I have to wonder
> what other performance problems are lurking out of sight.)
> 
> These tags have zero value outside of CVS, so I would just like to drop
> them when converting the repository.  I don't see anything obvious in
> "hg help convert".  Am I missing something, i.e. is there an way to do
> this?

emacs .hgtags
hg ci

If anyone comes up with a non-silly reason to have 100k tags or even 10k
tags, we might look at improving the performance.

-- 
http://selenic.com : development and support for Mercurial and Linux