Could @geoffwozniak give some context here? The last time I knew, repo surgeon was not the top dog in the gcc git conversion race. Did that change, or is esr an unreliable narrator?
This was talked about for a long time on the mailing list, but once the GNU Cauldron happened in September 2019, it kind of lit a fire under the whole “let’s get this converted to Git” movement. There was already a mirror that many (including myself) were using and because the whole reposurgeon thing seemed stuck, some argued to just get on with it and use the existing mirror.
Some of the long-time contributors were a little more concerned about the tags and historical aspects of the repo, going back to the CVS days. As a result, the enthusiasm of the mirror and an existing conversion script waned. Personally, I was fine with the mirror.
At any rate, the wiki page lays out the pros and cons of each. It was sometime in December 2019 that the reposurgeon route was chosen. It’s somewhere in this thread (I’m too lazy to find the exact message).
the increase in throughput from Python is pretty breathtaking, at least an order of magnitude and would have been far more if it weren’t constrained by the slowness of svnadmin dump. Some of that was improved optimization of the algorithms – we knocked out one O(n**2) after translation
This makes me wonder whether the performance improvement is due to the language or the code refactoring/improvements that happened during the rewrite. In other words, could the speed ups be achieved in python too? I guess that the parallelization and garbage collection is where go shines and those seem to be responsible for the performance bump too.
From reading ESR’s various notes on this topic, it sounds like the core thing that made Go work better here is the greatly reduced space overhead for individual strings and objects.
Some context as people might have missed the recent report from esr: https://gitlab.com/esr/reposurgeon/blob/master/GoNotes.adoc
As Stroustrup put it, everyone wants a simple language plus a couple more features.
Could @geoffwozniak give some context here? The last time I knew, repo surgeon was not the top dog in the gcc git conversion race. Did that change, or is esr an unreliable narrator?
This was talked about for a long time on the mailing list, but once the GNU Cauldron happened in September 2019, it kind of lit a fire under the whole “let’s get this converted to Git” movement. There was already a mirror that many (including myself) were using and because the whole reposurgeon thing seemed stuck, some argued to just get on with it and use the existing mirror.
Some of the long-time contributors were a little more concerned about the tags and historical aspects of the repo, going back to the CVS days. As a result, the enthusiasm of the mirror and an existing conversion script waned. Personally, I was fine with the mirror.
At any rate, the wiki page lays out the pros and cons of each. It was sometime in December 2019 that the reposurgeon route was chosen. It’s somewhere in this thread (I’m too lazy to find the exact message).
In addition, a previous story about this with some more context on why reposurgeon was chosen: https://lobste.rs/s/ykr0ct/gcc_has_really_high_quality_git
This makes me wonder whether the performance improvement is due to the language or the code refactoring/improvements that happened during the rewrite. In other words, could the speed ups be achieved in python too? I guess that the parallelization and garbage collection is where go shines and those seem to be responsible for the performance bump too.
From reading ESR’s various notes on this topic, it sounds like the core thing that made Go work better here is the greatly reduced space overhead for individual strings and objects.
[Comment removed by author]
Which claims are you talking about?