Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Originally posted by phoronix View Post
    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.

    Comment


    • #3
      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.
      "Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."

      Comment


      • #4
        Originally posted by L_A_G View Post
        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.

        Comment


        • #5
          Originally posted by L_A_G View Post
          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?

          Comment


          • #6
            Originally posted by AndyChow View Post
            Given that GCC supports 8 languages, and 21+ architectures, parts of which aren't tested that often, keeping the whole history makes sense.
            How does it make sense? If they are rare and weird and haven't been touched in many years it makes sense to get rid of them.
            Anyway IMO during the migration from SVN to Git ESR should skip this altogether and migrate directly to LLVM. Just kidding. Not.

            Comment


            • #7
              Is there some gcc svn repository (serverside) snapshot that armchair experts could try converting to git using existing svn2git tool?

              Comment


              • #8
                Lets review some of the comedy gold in this scenario:
                1. A GCC dev is spending months on porting SVN into GCC by converting a python script (not part of GCC) into a golang binary (reference production compiler is not GCC).
                2. The problem could have been sorted out by renting a cloud instance for $50 for a day. Instead, Dozens of an extremely well known and otherwise productive (well, until recently) programmer-hours been spent on the project.
                3. A 40x performance improvement was suggested. 4x is estimated with potential for a bit more if more time is spent on the problem. 3x will be delivered if we're lucky.
                4. It's a one-off project: Around the world there are no more than a few hundred SVN trees in line for a git transfer. And none of those projects have similar issues with the python script.
                5. Go 2 is expected to come out by the time porting is complete.
                6. A few hacks of the script could have had it swap on a cheap SSD for a few days instead.
                7. It's not SVN that's holding back GCC. It's a combination of license issues (which can't and shouldn't be addressed on principle), technical issues (old code base with lots of craft to get things done) and administrative issues relating to allocation of resources (see above article).

                Or in other words (http://www.topedge.com/home/people/g...okes/b15.htm):

                Q: How many software engineers does it take to change a light bulb?
                A: None. That's a hardware problem.

                Comment


                • #9
                  The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time

                  Last edited by amehaye; 19 December 2018, 03:20 AM.

                  Comment


                  • #10
                    Originally posted by c117152 View Post
                    Lets review some of the comedy gold in this scenario:
                    1. A GCC dev is spending months on porting SVN into GCC by converting a python script (not part of GCC) into a golang binary (reference production compiler is not GCC).
                    A "GCC dev": https://geekz.co.uk/lovesraymond/wp-...ages/ep013.jpg is sadly rather accurate.

                    Originally posted by c117152 View Post
                    2. The problem could have been sorted out by renting a cloud instance for $50 for a day. Instead, Dozens of an extremely well known and otherwise productive (well, until recently) programmer-hours been spent on the project.
                    I wrote my own VCS-to-VCS converters in the past, and the big issue is that for a real good translation of an old and messy repo (such as GCC's), you won't do a one-off run. Instead, you run your tool, look for where it breaks down, fix your tool, rerun it, repeat ad infinitum.
                    So his 64GB machine didn't suffice (although I wonder how much state he really needs to keep in RAM) and renting a cloud instance for a day didn't suffice because it still took too long, and the rinse/repeat process isn't something that's done in a day even with a faster tool.

                    Originally posted by c117152 View Post
                    4. It's a one-off project: Around the world there are no more than a few hundred SVN trees in line for a git transfer. And none of those projects have similar issues with the python script.
                    There are still tons of SVN repos out there. SVN is still being developed.

                    Originally posted by c117152 View Post
                    7. It's not SVN that's holding back GCC. It's a combination of license issues (which can't and shouldn't be addressed on principle), technical issues (old code base with lots of craft to get things done) and administrative issues relating to allocation of resources (see above article).
                    ESR not working on GCC itself is a negligible loss for GCC, so why not let him spend his time on a project such as this? At least it's not a core GCC developer diverting their time on that. See his CV at http://www.catb.org/esr/resume.html: there's nethack and intercal-to-C compilers, but no mention of GCC.

                    Comment

                    Working...
                    X