Re: Branch and tag deletions

["Eric S. Raymond" <esr at thyrsus dot com>]

Joseph Myers <joseph@codesourcery.com>:
> I'm looking at the sets of branches and tags resulting from a GCC 
> repository conversion with reposurgeon.
> 
> 1. I see 227 branches (and one tag) with names like 
> cxx0x-concepts-branch-deleted-r131428-1 (this is out of 780 branches in 
> total in a conversion of GCC history as of a few days ago).  Can we tell 
> reposurgeon not to create such branches (and tags)?  I can't simply do 
> "branch /-deleted-r/ delete" because that command doesn't take a regular 
> expression.

Those dead branches were supposed to never be visible in the final
conversion.

They arise when a tag is created, then deleted, then recreated under
the same name. The dumpfile operations for the old tag can't simply
ignored, as part of its content could get copied forward from before
the delete to a branch that remains live.  So I recolor them, then
have logic to skip generating commits and tags from them. You;re
seeing dome leak through those guards, which is a bug.

I'm using a different and much simpler strategy in the analyzer rewrite;
this bug should be squashed when it lands.

> 2. gcc.lift has a series of "tag <something> delete" commands, generally 
> deleting tags that aren't official GCC releases or prereleases (many of 
> which were artifacts of how creating such tags was necessary to track 
> merges in the CVS and older SVN era).  But some such commands are 
> mysteriously failing to work.  For example I see
> 
> tag /ZLIB_/ delete
> reposurgeon: no tags matching /ZLIB_/
> 
> but there are tags ZLIB_1_1_3, ZLIB_1_1_4, ZLIB_1_2_1, ZLIB_1_2_3 left 
> after the conversion.  This isn't just an issue with regular expressions; 
> I also see e.g.
> 
> tag apple/ppc-import-20040330 delete
> reposurgeon: no tags matching apple/ppc-import-20040330
> 
> and again that tag exists after the conversion.

I knew there was a problem with those, but I have not diagnosed it
yet.  I know generally where it has to be and think it will be
relatively easy to clean up once I've dealt with the more pressing
issues.

Please file issues about these bugs so I can track then.

On the first one, it would be helpful if you could list some tags
that these match expressions fail to pick up from as early as
possible. Shortening the leading segment I need to load speeds up 
my test cycle significantly,
-- 
		<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>