Joseph Myers <jos...@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>