This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Hi Maxim,

On Fri, 2019-12-06 at 17:44 +0300, Maxim Kuvyrkov wrote:
> > On Sep 19, 2019, at 6:34 PM, Maxim Kuvyrkov <> wrote:
> > > On Sep 17, 2019, at 3:02 PM, Richard Earnshaw (lists) <> 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
> > .
> > 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 .
> 1. The conversion has all SVN live branches converted as branches under refs/heads/* .
> 2. The conversion has all SVN live tags converted as annotated tags under refs/tags/* .
> 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.
> 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.
> 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
>    -- should be live by Monday.

Should we go with the gcc-reparent.git repo now?

Where exactly should it be installed under
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?

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]