On Dec 16, 2019, Jeff Law <l...@redhat.com> wrote: > Yet Joseph just indicated today Maxim's conversion is missing some > branches. While I don't consider any of the missed branches important, > others might. More importantly, it raises the issue of what other > branches might be missing and what validation work has been done on > that conversion.
It also raises another issue, namely the ability to *incrementally* fix such problems should we find them after the switch-over. I've got enough experience with git-svn to tell that, if it missed a branch for whatever reason, it is reasonably easy to create a configuration that will enable it to properly identify the point of creation of the branch, and bring in subsequent changes to the branch, in such a way that the newly-converted branch can be easily pushed onto live git so that it becomes indistinguishable from other branches that had been converted before. I know very little about reposurgeon, but I'm concerned that, should we make the conversion with it, and later identify e.g. missed branches, we might be unable to make such an incremental recovery. Can anyone alleviate my concerns and let me know we could indeed make such an incremental recovery of a branch missed in the initial conversion, in such a way that its commit history would be shared with that of the already-converted branch it branched from? Anyway, hopefully we won't have to go through that. Having not just one but *two* fully independent conversions of the SVN repo to GIT, using different tools, makes it a lot less likely that whatever result we choose contains a significant error, as both can presumably help catch conversion errors in each other, and the odds that both independent implementations make the same error are pretty thin, I'd think. Now, would it be too much of a burden to insist that the commit graphs out of both conversions be isomorphic, and maybe mappings between the commit ids (if they can't be made identical to begin with, that is) be generated and shared, so that the results of both conversions can be efficiently and mechanically compared (disregarding expected differences) not only in terms of branch and tag names and commit graphs, but also tree contents, commit messages and any other metadata? Has anything like this been done yet? -- Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo Free Software Evangelist Stallman was right, but he's left :( GNU Toolchain Engineer FSMatrix: It was he who freed the first of us FSF & FSFLA board member The Savior shall return (true);
