GCC's Conversion To Git Is Still Turning Out To Be A Massive Headache

[phoronix]

Phoronix: GCC's Conversion To Git Is Still Turning Out To Be A Massive Headache

Remember earlier this month when GCC's long in the works conversion from SVN to Git was being held up by the lack of RAM on Eric S Raymond's system? Well, it turns out that's just part of the problem...

http://www.phoronix.com/scan.php?page=news_item&px=GCC-Git-Complexities

[chuckula]

At this stage it's probably best to take a modern development version of GCC and set it up as the initial seed of a GIT repository while ignoring all the older stuff that can go into legacy mode with SVN. Just get one correct version into GIT and start from there without worrying about making the GIT repo act as the historic archive for all of GCC.

[Michael]

At this stage it's probably best to take a modern development version of GCC and set it up as the initial seed of a GIT repository while ignoring all the older stuff that can go into legacy mode with SVN. Just get one correct version into GIT and start from there without worrying about making the GIT repo act as the historic archive for all of GCC.

The motivation for having at least some modern backhistory on master/trunk and maintained branches is for still being able to easily bisect regressions without having to switch back over to SVN for doing any bisects beyond the initial commit.

[carewolf]

The motivation for having at least some modern backhistory on master/trunk and maintained branches is for still being able to easily bisect regressions without having to switch back over to SVN for doing any bisects beyond the initial commit.

Well, perhaps things work if they contrain themselves to ~10 years of history, instead of all.. emm. 30? years of history.

[reavertm]

Meanwhile KDE folks converted all their svn repos to git ages ago with their own https://github.com/svn-all-fast-export/svn2git
Perhaps mr Raymonds should stop reinventing the wheel?

[FireBurn]

Meanwhile KDE folks converted all their svn repos to git ages ago with their own https://github.com/svn-all-fast-export/svn2git
Perhaps mr Raymonds should stop reinventing the wheel?

I don't think that's comparing like for like, KDE was mostly small repositories in comparison to GCC, the feature work was also much bigger branch merges than would have been seen in GCC

[anarki2]

It's rather surprising that to this day, noone has come up with a reliable and scalable conversion tool between 2 such mainstream VCSes.

[nanonyme]

It's rather surprising that to this day, noone has come up with a reliable and scalable conversion tool between 2 such mainstream VCSes.

It's not that bad if you don't care about doing intensive surgery on your repo. SVN trunk maps with Git master, SVN has arbitrary paths but sensible people use strict branch and tag semantics with SVN which can be translated into Git with ease. From DCVS to another it's most likely even easier

[torsionbar28]

I still don't understand why this is a performance problem. Is he trying to do some kind of live conversion without taking the repository offline? I.e. still accepting new commits while the conversion is in process? We can brute force RC5-64 searching 15,769,938,165,961,326,592 keys for a solution, but we don't have the computational power to migrate some code from one server to another?

[Mark Rose]

It's rather surprising that to this day, noone has come up with a reliable and scalable conversion tool between 2 such mainstream VCSes.

The problem seems to be oddities in their SVN repo, and it's the repair tool that's taking up the RAM.