On Mon, Jul 22, 2019 at 5:05 AM Maxim Kuvyrkov <maxim.kuvyr...@linaro.org> wrote: > > > On Jul 16, 2019, at 5:14 PM, Maxim Kuvyrkov <maxim.kuvyr...@linaro.org> > > wrote: > > > >> On Jul 16, 2019, at 3:34 PM, Jason Merrill <ja...@redhat.com> wrote: > >> > >> On Tue, Jul 16, 2019 at 12:18 PM Maxim Kuvyrkov > >> <maxim.kuvyr...@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. Jason
