State of the reposurgeon conversion

Joseph Myers joseph@codesourcery.com
Mon May 20 23:14:00 GMT 2019


On Mon, 20 May 2019, Richard Biener wrote:

> There's not many details there but I always thought that the
> "interesting" parts of the GCC history (official branches and trunk)
> do _not_ contain merge commits so the GCC history forms a tree
> rather than a DAG.  (I'm not sure if there's an easy way to verify
> whether there are any merge commits on a specific branch)

There are plenty of merge commits on development branches, which are of 
value to keep so that changes made on such a branch are clearly 
distinguished from those that were merged into it.

> There may be merges hidden inside the cvs2svn converted part
> as well as in user branches (definitely merges from trunk to branch).

cvs2svn history won't have merge commits in any form that can be handled 
automatically (simply because CVS doesn't have any form of merge tracking 
that could be converted to SVN - and SVN's own merge tracking long 
postdates the repository conversion from CVS).

What it *does* have is messed up branchpoints (cvs2svn had a habit of 
picking the wrong commit to copy to form a branch based on the 
branchpoints for each individual ,v file in CVS - and then fixing it up 
with another synthetic commit to restore files to the actual form they had 
when the branch was created - or something like that, anyway, and similar 
issues for tags).  If you're looking at history around the creation of an 
old branch or tag, those are confusing in practice.  reposurgeon has logic 
to fix up at least some such messes created by cvs2svn and pick a more 
sensible branchpoint.

(It's possible some branches from that era genuinely don't start with a 
copy of a single revision from trunk, or whatever branch they were based 
on - CVS branch creation is not an atomic operation and could end up with 
inconsistent versions of different files.  But cvs2svn was bad in the 
common case where there is a single revision that was copied, but cvs2svn 
chose some other revision + fixups anyway.)

-- 
Joseph S. Myers
joseph@codesourcery.com



More information about the Gcc-patches mailing list