On 31/12/2019 13:42, Joseph Myers wrote: > On Mon, 16 Dec 2019, Jeff Law wrote: > >>> Joseph Myers has made his choice. He has said repeatedly that he >>> wants to follow through with the reposurgeon conversion, and he's >>> putting his effort behind that by writing tests and even contributing >>> code to reposurgeon. >>> >>> We'll get this done faster if nobody is joggling his elbow. Or mine. >> And just to be clear, my preference is for reposurgeon, if it's ready. >> But if it isn't, then I'm absolutely comfortable dropping back to >> Maxim's conversion or even the existing mirror. > > As the remaining changes being made to the reposurgeon conversion are of > the form "tidy things up where reposurgeon is already making a reasonable > conservative choice but minor improvements are still possible", I think > it's very clearly ready and propose doing the actual conversion with > reposurgeon over the weekend of 11/12 January [*], with whatever > improvements to commit messages and authors are ready by then. (People > would then be free to note issues found afterwards, with the potential to > address them if some other version control system takes over from git in > 20 years' time, just as some issues from cvs2svn are being addressed in > this conversion.) > > This is explicitly not aiming for perfection, but saying that having some > improved commit message summaries and authors, based on a combination of > sufficiently safe heuristics and manual review of cases heuristics suggest > may be questionable and that can be reviewed in time, without trying to > have the best possible commit message or author in every case, is better > than falling back to only the original commit messages and only using the > committer as the author. > > [*] The time taken by a reposurgeon conversion is actually dominated by > time spent in git (git-fast-import takes about four hours to import the > repository, git gc --aggressive takes over an hour to repack it > afterwards) and in validation against SVN, not in reposurgeon itself, so > doesn't take a whole weekend, but there will be other things such as hook > setup and testing and documenting usage of the repository. >
We can develop and test the hook setup on one of the trial repositories. In fact, we could probably open one of them up to allow commits from the community on the understanding that all such commits are for testing purposes only and will be lost during the final conversion. That will give folk an opportunity to test their own local setups so that when the switch does occur they are well prepared. R.
