Originally posted by stevecrox
View Post
Announcement
Collapse
No announcement yet.
The GCC Git Conversion Heats Up With Hopes Of Converting Over The Holidays
Collapse
X
-
- Likes 6
-
If they really need to switch to Git, why not simply make a new branch and only do that on the new Git, while the old SVN is archived as read-only for the time being. Must be cheaper and easier to keep that so rather than converting something that, most likely, in the end won't be trusted anyway.
- Likes 1
Comment
-
Originally posted by Spam View PostIf they really need to switch to Git
why not simply make a new branch and only do that on the new Git
while the old SVN is archived as read-only for the time beingLast edited by CommunityMember; 08 December 2019, 07:21 PM.
Comment
-
Originally posted by discordian View PostConversion is one thing, but I don't get why they did not convert to git and then do the cleanup there. Finding identical (sub)directories in git is rather easy with the hashes being used, and access is generally faster than with svn.
- Likes 3
Comment
-
Originally posted by CommunityMember View PostTechnically, they probably don't need to switch, although switching has some well understood benefits for a large code base such as gcc.
There are certainly some projects that have made that choice. But there are those in the gcc project that do not wish to lose the author attribution, code fragment, and dead branch information in the historical record using the common tools they will be using going forward (git). Note to add the the various challenges, the svn repo was itself migrated from cvs, which generated a different set of artifacts.
The svn repo will probably be kept (essentially) forever, as no conversion is likely going to be absolutely perfect, and having access to the historical base might also come in valuable by some computing archivist from the 22nd century trying to understand what the grey beards contributed. Of course, whether one will be able to find a working subversion binary in the 22nd century is a different question.
To further prove how open source projects often suffer from such insanity: I've read elsewhere that KDE refused to use GitHub because 'it isn't FOSS'. At the end of the day, git is git. Even if GitHub disappeared tomorrow, that would not affect the project in the least. it would be relatively easy to use a different platform or host your own. If the loss of 'bugs' or 'issues' on GitHub's issue tracker is something you are worried about, you can simply have your own API that logs these to a database as they come in, as GitHub not only has a full API, but they also have event hooks. What did KDE do? They instead opted to go with an incomplete and immature platform. A platform where you can't even reset your own password if you don't remember your 'username'. A platform that is awkward to navigate. A platform that has likely costed a ton of development time and an insignificant amount of money for hosting. All in the name of keeping everything FOSS. While one can appreciate the spirit of that approach. That platform limits developer contributions to those who can be bothered to have yet another account, learn yet another system that isn't an established industry standard, and deal with the inevitable bugs of that platform. Their choice has costed them both talent and money, and this is evidenced by their constant call for help both in the way of developers and dollars.
Don't even get me started on some of the other Open Source nonsense we've been witness to in the past. This is not to say that this can't happen in closed source environments as well. However, when a company's bottom line is erm...on the line, they tend to value developer/support time and cost of implementation over all else, which in turn tends to work out well for everyone (except in some of the crazier 'big business' scenarios I've seen, which are almost always related to incompetence).
- Likes 2
Comment
-
Originally posted by cybertraveler View PostI don't know why some of you are so salty or angry about this.
I just see a guy who wants to carefully and cleanly convert the data and has been working on doing this in the spare time he has available.
Any cowboy with some basic coding knowledge could do a fast conversion using existing tools or even some homebrew software. However, the result would almost certainly be an imperfect conversion that would leave a trail of confusion and problems for years to come. But that cowboy would have "done his job" and received praise for doing it, so he probably wouldn't care. I've met those kind of coders; they are numerous. There are far fewer coders who are methodical, far-thinking and considerate.
If I was a GCC dev I'd prefer that this guy takes another 2 years doing this task properly instead of it being done quickly with potential messy fallout.
Comment
-
This page contains some suggestions about the difficult of converting the gcc repository.
Basically it seems that it is not a simple import, but some revision/changeset have to be tweaked in order to solve some artifact related to the past cvs->svn conversion. In this the Maxim's solution is described as inferior than the ESR's conversion via Reposurgeon tool.
Anyway the GCC history starts from 1988, and the current gcc repository contains about 350 branches spread over ~280000 commits.
- Likes 3
Comment
Comment