David Malcolm <dmalc...@redhat.com>:
> > What kind of mechanical transformation or hand-editing would add value for
> >you?
>
> Will the resulting git commits have some kind of metadata identifying
> the corresponding SVN revision?
That's what the --legacy option does. I think Jason plans to use it.
I've noted previously that I actually recommend against this based on
previous experience with Subversion conversions. You get a lot of
clutter in the result and demand for such lookups (especially *outside
the specific context of a buglist*) tends to drop off faster than
people expect. But that policy decision isn't mine to make.
> Similarly, our bugzilla automatically turns text like "r226697" into
> links to the relevant commit in SVN. I don't know if there's a way to
> maintain those links for git (beyond e.g. creating a named tag for every
> r[0-9]+, but that's clearly insane), so presumably we'd want to keep the
> old SVN web interface around to service those bugzilla URLs?
There is no way to maintain those links for git, so yes, you want to
keep a read-only Subversion instance around.
This also lowers the utility of keeping the legacy-ID in every commit.
> So it'd be great if a script could identify those commit titles that are
> just the top of ChangeLog entries, scrape the gcc-patches mailing list
> archives for try to locate the Subject lines of the pertinent patches
> (and clean away extraneous [PATCH] or [PING] fragments, though other
> fragments may be pertinent e.g. identifying subsystems). Potentially it
> could also add the URL of the discussion in the list archive. Clearly a
> non-trivial task though.
There was already some discussion of this. If someone else is willing
to digest the gcc-patches archives into committer/date/subject-line
triples I'll see what I can do.
> Thanks; hope this is constructive
Yes, very much the sort of thing I was looking for.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
