Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Richard Biener <richard dot guenther at gmail dot com>]

On Fri, Aug 2, 2019 at 10:41 AM Maxim Kuvyrkov
<maxim.kuvyrkov@linaro.org> wrote:
>
> > On Aug 1, 2019, at 11:43 PM, Jason Merrill <jason@redhat.com> wrote:
> >
> > On Mon, Jul 22, 2019 at 5:05 AM Maxim Kuvyrkov
> > <maxim.kuvyrkov@linaro.org> wrote:
> >>
> >>> On Jul 16, 2019, at 5:14 PM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
> >>>
> >>>> On Jul 16, 2019, at 3:34 PM, Jason Merrill <jason@redhat.com> wrote:
> >>>>
> >>>> On Tue, Jul 16, 2019 at 12:18 PM Maxim Kuvyrkov
> >>>> <maxim.kuvyrkov@linaro.org> wrote:
> >>>>>
> >>>>> Hi Everyone,
> >>>>>
> >>>>> I've been swamped with other projects for most of June, which gave me time to digest all the feedback I've got on GCC's conversion from SVN to Git.
> >>>>>
> >>>>> The scripts have heavily evolved from the initial version posted here.  They have become fairly generic in that they have no implied knowledge about GCC's repo structure.  Due to this I no longer plan to merge them into GCC tree, but rather publish as a separate project on github.  For now, you can track the current [hairy] version at https://review.linaro.org/c/toolchain/gcc/+/31416 .
> >>>>>
> >>>>> The initial version of scripts used heuristics to construct branch tree, which turned out to be error-prone.  The current version parse entire history of SVN repo to detect all trees that start at /trunk@1.  Therefore all branches in the converted repo converge to the same parent at the beginning of their histories.
> >>>>>
> >>>>> As far as GCC conversion goes, below is what I plan to do and what not to do.  This is based on comments from everyone in this thread:
> >>>>>
> >>>>> 1. Construct GCC's git repo from SVN using same settings as current git mirror.
> >>>>> 2. Compare the resulting git repo with current GCC mirror -- they should match on the commit hash level for trunk, branches/gcc-*-branch, and other "normal" branches.
> >>>>> 3. Investigate any differences between converted GCC repo and current GCC mirror. These can be due to bugs in git-svn or other misconfigurations.
> >>>>> 4. Import git-only branches from current GCC mirror.
> >>>>> 5. Publish this "raw" repo for community to sanity-check its contents.
> >>>>
> >>>> Why not start from the current mirror?  Perhaps a mirror of the mirror?
> >>>
> >>> To check that git-svn is self-consistent and generates same commits now as it was several years ago when you setup the current mirror.
> >>
> >> Unfortunately, current mirror does not and could not account for rewrites of SVN commit log messages.  For trunk the histories of diverge in 2008 due to commit message change of r138154.  This is not a single occurrence; I've compared histories only of trunk and gcc-6-branch, and both had commit message change (for gcc-6-branch see r259978).
> >>
> >> It's up to the community is to weigh pros and cons of re-using existing GCC mirror as conversion base vs regenerating history from scratch:
> >>
> >> Pros of using GCC mirror:
> >> + No need to rebase public git-only branches
> >> + No need to rebase private branches
> >> + No need to rebase current clones, checkouts, work-in-progress trees
> >>
> >> Cons of using GCC mirror:
> >> - Poor author / committer IDs (this breaks patch statistics software)
> >> - Several commit messages will not be the current "fixed" version
> >>
> >> Thoughts?
> >
> > I'm still inclined to stick with the mirror.  I would expect patch
> > statistics software to be able to be taught about multiple addresses
> > for the same person.
>
> Patch tracking software breaks on emails like <fxcoudert@138bc75d-0d04-0410-961f-82ee72b054a4> , where 38bc75d-0d04-0410-961f-82ee72b054a4 is not a reasonable domain name.
>
> For completeness, I'll generate and upload a repo based on current mirror with all branches and tags converted.
>
> In the end, I don't care much to which version of the repo we switch, as long as we switch.

I think that if we have something clearly better than the current
mirror we should use that.  rebasing might
be a hassle but git should make that reasonably easy - proper
instructions how to do that are of course
welcome (just add a new remote, adjust all local branches remote and
then rebase?).

Richard.

> --
> Maxim Kuvyrkov
> www.linaro.org
>
>
>
>