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

[Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>]

> On Jan 10, 2020, at 10:33 AM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
> 
>> On Jan 9, 2020, at 5:38 AM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
>> 
>> On Wed, Jan 08, 2020 at 11:34:32PM +0000, Joseph Myers wrote:
>>> As noted on overseers, once Saturday's DATESTAMP update has run at 00:16 
>>> UTC on Saturday, I intend to add a README.MOVED_TO_GIT file on SVN trunk 
>>> and change the SVN hooks to make SVN readonly, then disable gccadmin's 
>>> cron jobs that build snapshots and update online documentation until they 
>>> are ready to run with the git repository.  Once the existing git mirror 
>>> has picked up the last changes I'll make that read-only and disable that 
>>> cron job as well, and start the conversion process with a view to having 
>>> the converted repository in place this weekend (it could either be made 
>>> writable as soon as I think it's ready, or left read-only until people 
>>> have had time to do any final checks on Monday).  Before then, I'll work 
>>> on hooks, documentation and maintainer-scripts updates.
>> 
>> Where and when and by who was it decided to use this conversion?
> 
> Joseph, please point to message on gcc@ mailing list that expresses consensus of GCC community to use reposurgeon conversion.  Otherwise, it is not appropriate to substitute one's opinion for community consensus.
> 
> I want GCC community to get the best possible conversion, being it mine or reposurgeon's.  To this end I'm comparing the two conversions and will post my results later today.
> 
> Unfortunately, the comparison is complicated by the fact that you uploaded only "b" version of gcc-reposurgeon-8 repository, which uses modified branch layout (or confirm that there are no substantial differences between "7" and "8" reposurgeon conversions).

There are plenty of difference between reposurgeon and svn-git conversions; today I've ignored subjective differences like author and committer entries and focused on comparing histories of branches.

Redhat's branches are among the most complicated and below analysis is difficult to follow.  It took me most of today to untangle it.  Let's look at redhat/gcc-9-branch.

TL;DR:
1. Reposurgeon conversion has extra history (more commits than intended) of redhat/gcc-4_7-branch@182541 merged into redhat/gcc-4_8-branch, which is then propagated into all following branches including redhat/gcc-9-branch.
2. Svn-git conversion has redhat/gcc-4_8-branch with history corresponding to SVN history, with no less and no more commits.
3. Other branches are likely to have similar issues, I didn't check.
4. I consider history of reposurgeon conversion to be incorrect.
5. The only history artifact (extra merges in reparented branches/tags) of svn-git conversion has been fixed.
6. I can appreciate that GCC community is tired of this discussion and wants it to go away.

Analysis:
Commit histories for redhat/gcc-9-branch match up to history inherited from redhat/gcc-4_8-branch (yes, redhat's branch history goes into ancient branches).  So now we are looking at redhat/gcc-4_8-branch, and the two conversions have different commit histories for redhat/gcc-4_8-branch.  This is relevant because it shows up in current development branch.  The histories diverge at r194477:
------------------------------------------------------------------------
r194477 | jakub | 2012-12-13 13:34:44 +0000 (Thu, 13 Dec 2012) | 3 lines

svn merge -r182540:182541 svn+ssh://gcc.gnu.org/svn/gcc/branches/redhat/gcc-4_7-branch
svn merge -r182546:182547 svn+ssh://gcc.gnu.org/svn/gcc/branches/redhat/gcc-4_7-branch
------------------------------------------------------------------------
Added: svn:mergeinfo
## -0,0 +0,4 ##
   Merged /branches/redhat/gcc-4_4-branch:r143377,143388,144574,144578,155228
   Merged /branches/redhat/gcc-4_5-branch:r161595
   Merged /branches/redhat/gcc-4_6-branch:r168425
   Merged /branches/redhat/gcc-4_7-branch:r182541,182547
------------------------------------------------------------------------

To me this looks like cherry-picks of r182541 and r182547 from redhat/gcc-4_7-branch into redhat/gcc-4_8-branch.

[1] Note that commit r182541 is itself a merge of redhat/gcc-4_6-branch@168425 into redhat/gcc-4_7-branch and cherry-picks from the other branches.  It is an actual merge (not cherry-pick) from redhat/gcc-4_6-branch@168425 because r168425 is the only commit to redhat/gcc-4_6-branch@168425 not present on trunk.  The other branches had more commits to their histories, so they can't be represented as git merges.

Reposurgeon commit for r194477 (e601ffdd860b0deed6d7ce78da61e8964c287b0b) merges in commit for r182541 from redhat/gcc-4_7-branch bringing *full* history of redhat/gcc-4_7-branch into redhat/gcc-4_8-branch.

Svn-git commit for r194477 (98d65ca0b53332e7c9cb62dfe85936a0e71d077e) cherry-picks commits r182541 and r182547 from redhat/gcc-4_7-branch.  As part of cherry-picking commit r182541 svn-git conversion merges redhat/gcc-4_6-branch@168425 into redhat/gcc-4_8-branch.  Merge from redhat/gcc-4_6-branch@168425 is expected, see [1].

--
Maxim Kuvyrkov
https://www.linaro.org