The Debate Over GCC's SVN-to-Git Conversion Approach Won't Be Settled This Year

[bug77]

It seems like using a general use tool for the conversion makes more sense than a ad-hoc set of bash scripts, since the general use tool can allow other projects to benefit from all of the improvements that have gone into it. So reposurgeon seems to be the best choice for this reason, since it can also help other projects.

Postulating the conclusion before reaching it?
Why would a generic tool make more sense? A set of scripts specifically tailored for the job can be the better choice

[CommunityMember]

The conversion is proving to be hard because the original itself is full of botched history, thanks to the sloppiness of SVN/CVS.

Some of the issue goes back before that to RCS. The various past VCS conversions have added to the borkage. Such breakage in past conversions has been accepted as the reality of needing to break a few eggs when you make the omelette, and regardless of the which conversion tool is chosen there will be new egg shells lying around to clean up.

[Ipkh]

Color me impressed with all this effort to completely automate the process. Reasonable project management would have the auto tool flag the commits it can't guarantee for manual intervention. You could even farm out the manual review to the community at large given the nature of the project.
But that probably makes too much sense. Even Microsoft migrated with less drama.

[Neraxa]

It seems like using a general use tool for the conversion makes more sense than a ad-hoc set of bash scripts, since the general use tool can allow other projects to benefit from all of the improvements that have gone into it. So reposurgeon seems to be the best choice for this reason, since it can also help other projects.

Another option was to use the existing Git mirror which does not have the full history but keep SVN online in perpetuity. This might require some people to back and manully import a revision if they need it. Actually SVN will have to be kept online in perpetuity for what I think is a 100% gaurantee of errors in the svn to git conversion, so someone may need to go back and look at the SVN anyway and it needs to be kept.

But I think a full conversion is a technically better solution but the SVN needs to be kept around just in case.

[Britoid]

The GCC folks should let the Debian crowd vote on the best tool to migrate from SVN to Git.

The Debian crowd will decide on a direction ... and in a few years they will decide on a direction AGAIN.

Except the second vote will just end up confirming what people are really doing because no one followed the first vote.

[NotMine999]

The GCC folks should let the Debian crowd vote on the best tool to migrate from SVN to Git.

The Debian crowd will decide on a direction ... and in a few years they will decide on a direction AGAIN.

[Britoid]

Some governments have less bureaucracy.

[szymon_g]

Just copy and past these damn files with nautilus or something like that. Or MC

[Veto]

Because you need to be able to search history to track down the origin of a bug, the reason why a change was introduced, to perform a bisection while looking for a regression, to be able to backport patches to older branches... I could go on for a while. For large projects having accurate and functioning history in your VCS is extremely important.

You can still do all the things you mention by keeping history in the old system. You can even argue that history will be more accurate by nature, if not converting it. Maybe it will incur some minor inconvenience for these use cases for a period of time. But the usefulness of "old" history very quickly fades, and a couple of years ahead most will have no use for it anyway.

The other thing is, the burden of postponing the switch and afterwards dragging along a giant repository is very real now and going forward.

How many mega/gigabytes is the converted repository? I guess 'git clone --depth ...' will be mandatory from the beginning

[milkylainen]

Oh my.
Color me surprised!