On Fri, 1 Nov 2019, Eric S. Raymond wrote: > Joseph Myers <jos...@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 jos...@codesourcery.com
