> On Sep 19, 2019, at 6:34 PM, Maxim Kuvyrkov <maxim.kuvyr...@linaro.org> wrote: > >> On Sep 17, 2019, at 3:02 PM, Richard Earnshaw (lists) >> <richard.earns...@arm.com> wrote: >> >> At the Cauldron this weekend the overwhelming view for the move to GIT soon >> was finally expressed. >> > ... >> >> So in summary my proposed timetable would be: >> >> 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. >> >> Doing this over the new year holiday period has both advantages and >> disadvantages. On the one hand the traffic is light, so the impact to most >> developers will be quite low; on the other, it is a holiday period, so >> getting the right key folk to help might be difficult. I won't object >> strongly if others feel that slipping a few days (but not weeks) would make >> things significantly easier. > > The timetable looks entirely reasonable to me. > > 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/* . 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 https://git.linaro.org/people/maxim-kuvyrkov/gcc-reparent.git/ -- should be live by Monday. Finally, there seems to be quite a few misunderstandings about the scripts I've developed and their limitations. Most of these misunderstanding stem from assumption that all git-svn limitations must apply to my scripts. That's not the case. SVN merges, branch/tag reparenting, adjusting of commit logs are all handled correctly in my scripts. I welcome criticism with pointers to revisions which have been incorrectly converted. The general conversion workflow is (this really is a poor-man's translator of one DAG into another): 1. Parse SVN history of entire SVN root (svn log -qv file:///svnrepo/) and build a list of branch points. 2. From the branch points build a DAG of "basic blocks" of revision history. Each basic block is a consecutive set of commits where only the last commit can be a branchpoint. 3. Walk the DAG and ... 4. ... use git-svn to individually convert these basic blocks. 4a. Optionally, post-process git result of basic block conversion using "git filter-branch" and similar tools. Git-svn is used in a limited role, and it does its job very well in this role. Regards, -- Maxim Kuvyrkov https://www.linaro.org
