On 11/12/2019 15:30, Dennis Luehring wrote: > the differences between Maxim and Erics final result will hopefully show > the open bugs in both tools > and allow fixing - i think this compare phase is needed if the result > should be the best possible >
I don't disagree. But I don't think it's as simple as just comparing the tips in reality. Though that is certainly a major part of it. One of the things I've discovered while working on this is that subtle errors in recovering the history properly can lead to "git blame" hitting the wrong path and thus giving confusing answers. Most of those problems date back to the CVS era, but they are there and they probably will show through in the final conversion if we don't get it right, even if they appear to be ancient history. Having to go back to the SVN repos to do archaeology will be painful, especially as SVN becomes less and less used by developers. R. PS. I'm not trying to suggest that Maxim's conversion has got this wrong. Just that it is an issue that has come to light as I've been working on this, and I do know that the plain git svn conversion *is* wrong in this area. > Am 11.12.2019 um 16:19 schrieb Jonathan Wakely: >> On Wed, 11 Dec 2019 at 15:03, Richard Earnshaw (lists) wrote: >> > I wouldn't bother with that. There are known defects in the version of >> > reposurgeon that I used to produce that which have since been >> fixed. It >> > was *never* the point of that upload to ask for correctness checks on >> > the conversion (I said so at the time). Instead it was intended to >> > demonstrate the improvements to the commit summaries that I think we >> can >> > make. >> >> My concern is that there is no conversion done using reposurgeon that >> *can* be used to do correctness checks. > >
