GCC Is Still Months Away From Transitioning To Git, Reposurgeon Being Ported To Golang

[AndyChow]

I personally question the point of needing the whole SVN version history, or at least a massive part of it, converted to Git. The way I would do it is just to move over a history up to some recent or semi-recent sharp release and then just work from this and keep the legacy SVN around for the few instances it's necessary, maybe just keeping it offline on a disc and a couple of backups once it's pretty much lived out it's usefulness.

Seriously, when you move house throwing out old crap you haven't touched in years is what any sane person does. The same thing applies to moving old projects to a new version control system.

Given that GCC supports 8 languages, and 21+ architectures, parts of which aren't tested that often, keeping the whole history makes sense.

I'm also guessing that reposurgeon is the real goal of this exercise. There can be no better test than migrating GCC. If ESR wants to take a few years to make it happen, why not?

[cybertraveler]

I personally question the point of needing the whole SVN version history, or at least a massive part of it, converted to Git. The way I would do it is just to move over a history up to some recent or semi-recent sharp release and then just work from this and keep the legacy SVN around for the few instances it's necessary, maybe just keeping it offline on a disc and a couple of backups once it's pretty much lived out it's usefulness.

Seriously, when you move house throwing out old crap you haven't touched in years is what any sane person does. The same thing applies to moving old projects to a new version control system.

Could be useful for easily bisecting a more complete history to find the source of bugs. Michael does this on the Linux git tree to find issues.

I'm sure it's still doable if they keep the old tree in SVN, it's just more complicated.

In general, I think porting the history to git will make people's lives easier. All data in one place and parsable using one set of modern tools.

[L_A_G]

I personally question the point of needing the whole SVN version history, or at least a massive part of it, converted to Git. The way I would do it is just to move over a history up to some recent or semi-recent sharp release and then just work from this and keep the legacy SVN around for the few instances it's necessary, maybe just keeping it offline on a disc and a couple of backups once it's pretty much lived out it's usefulness.

Seriously, when you move house throwing out old crap you haven't touched in years is what any sane person does. The same thing applies to moving old projects to a new version control system.

[bachchain]

Hopefully in 2019 we'll finally see GCC switch over to Git.

Don't worry, I'm sure he'll think of some other reason to delay it back to 2022. My guess is on developing an intermediary versioning system from scratch.

[phoronix]

Phoronix: GCC Is Still Months Away From Transitioning To Git, Reposurgeon Being Ported To Golang

2018 sadly wasn't the year that the GNU Compiler Collection (GCC) transitioned to a Git workflow for developing this flagship open-source compiler... But Eric S Raymond does continue making progress on being able to convert the GCC tree from SVN to Git...

http://www.phoronix.com/scan.php?page=news_item&px=GCC-Reposurgeon-Py-To-Go-90