Re: Proposal for the transition timetable for the move to GIT

[Segher Boessenkool <segher at kernel dot crashing dot org>]

Hi!

On Mon, Dec 16, 2019 at 10:53:05AM +0100, Mark Wielaard wrote:
> On Fri, 2019-12-06 at 17:44 +0300, Maxim Kuvyrkov wrote:
> > > On Sep 19, 2019, at 6:34 PM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
> > > > On Sep 17, 2019, at 3:02 PM, Richard Earnshaw (lists) <Richard.Earnshaw@arm.com> wrote:
> > > > 
> > > > Monday 16th December 2019 - cut off date for picking which git conversion to use
> > > > 
> > > > Tuesday 31st December 2019 - SVN repo becomes read-only at end of stage 3.
> > > > 
> > > > Thursday 2nd January 2020 - (ie read-only + 2 days) new git repo comes on line for live commits.
> > > 
> > > I have regenerated my primary version this week, and it's up at
> > > https://git.linaro.org/people/maxim-kuvyrkov/gcc-pretty.git/ .
> > > So far I have received only minor issue reports about it, and all known problems have been fixed.
> > > I could use a bit more scrutiny :-).
> > 
> > I think now is a good time to give status update on the svn->git conversion I maintain.
> > See https://git.linaro.org/people/maxim-kuvyrkov/gcc-pretty.git/ .
> > 
> > 1. The conversion has all SVN live branches converted as branches under refs/heads/* .

That is true as far as I can see.  All branches I care about are there,
at least, and I don't see anything missing.

> > 2. The conversion has all SVN live tags converted as annotated tags under refs/tags/* .

Yup.

> > 3. If desired, it would be trivial to add all deleted / leaf SVN branches and tags.
> >    They would be named as branches/my-deleted-branch@12345,
> >    where @12345 is the revision at which the branch was deleted.
> >    Branches created and deleted multiple times would have separate entries
> >    corresponding to delete revisions.

I don't think this is desirable.

> > 4. Git committer and git author entries are very accurate
> >    (imo, better than reposurgeon's, but I'm biased).
> >    Developers' names and email addresses are mined from commit logs,
> >    changelogs and source code and have historically-accurately attributions
> >    to employer's email addresses.

They are very good, yes.  I have verified this *a lot*, months ago.  This
was all ready to go before the Cauldron.

> > 5. Since there is interest in reparenting branches to fix cvs2svn merge issues,
> >    I've added this feature to my scripts as well (turned out to be trivial).
> >    I'll keep the original gcc-pretty.git repo intact and will upload the new one at
> >    https://git.linaro.org/people/maxim-kuvyrkov/gcc-reparent.git/
> >    -- should be live by Monday.
> 
> Should we go with the gcc-reparent.git repo now?

I don't actually know what the difference is.  As far as I understand it
changes nothing for anything from this century, so either is fine with me.
And it is not very useful to have this old history cleaned up a bit: the
really *big* problem with the old history is that a) people did omnibus
commits a lot, not small self-contained commits changing one thing only;
and b) we really need to have the motivation that goes with those patches,
but that is not available (no mail archives).

> Where exactly should it be installed under https://gcc.gnu.org/git/
> Replacing the existing gcc.git will be confusing, but then how would we
> name the repo that will become the main git gcc repo in 2 weeks?

I think we should rename the old gcc.git mirror.  That pain is temporary.

> Where are the tools/scripts that should be installed on gcc.gnu.org to
> keep it up to date during the next 2 week transition period?

I think Maxim mentioned it before, but it's hard to find in this
humonguous thread :-)


Segher