Re: Fixing cvs2svn branchpoints

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 1 Nov 2019, Eric S. Raymond wrote:

> Joseph Myers <joseph@codesourcery.com>:
> > Here are complete lists of reparentings I think should be done on the 
> > commits that start branches, along with my notes on branches with messy 
> > initial commits but where I don't think any reparenting should be done.  
> > The REPARENT: lines have the meaning I described in 
> > <https://gcc.gnu.org/ml/gcc/2019-10/msg00127.html>.
> 
> Please leave this as an issue on the gcc-conversion bugtracker.

Done.  <https://gitlab.com/esr/gcc-conversion/issues/1>.

As noted there, I think this ought just to be a single reposurgeon 
reparent command for each of those 39 REPARENT lines, but I'm wary of 
adding those 39 reparent commands in a merge request without testing, and 
don't have any systems with more than 128 GB of memory to hand to test on.

(Incidental note: I'm taking the reparent syntax from the reposurgeon 
sources, that command doesn't seem to be documented in reposurgeon.adoc 
although it used to be documented in reposurgeon.xml.)

A similar issue may well apply to some tags, since tags and branches are 
essentially the same thing in SVN, and I hope to make such checks for tags 
as well.

> >There are also cases where cvs2svn found a good branchpoint, but
> >represented the branch-creation commit in a superfluously complicated
> >way, replacing lots of files and subdirectories by copies of different
> >revisions.
> 
> Yes, reposurgeon has logic to detect and deal with this automatically.
> The assumption it makes is that the branch should root to the most
> recent revision that CVS did a copy from. This is simple and seems to
> give satisfactory results.

Once we have a full conversion we should extract details from it of the 
branch roots reposurgeon identified, for further checks on them.

There are lots of mid-branch commits that also have commit messages of the 
form "This commit was manufactured by cvs2svn to create branch 'X'".  
Those mid-branch commits should *not* be turned into merge commits.  The 
typical situation resulting in such a mid-branch commit was that a file 
(typically a testcase) first created on HEAD then got backported to a 
branch, so cvs2svn means that commit created the branch *for that 
particular file" (so it's typically part of a cherry-pick, not a merge, 
though some CVS-era merges may have created such commits as well).

> Which reminds me. I found a bunch of "svnmerge-integrated" properites
> in the history. Should I treat those as though they were mergeinfo
> properies and make branch merges from them?

I think that's what those properties logically are, so making them into 
merges makes sense if that's easy to do.

-- 
Joseph S. Myers
joseph@codesourcery.com