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

    http://www.phoronix.com/scan.php?pag...on-Py-To-Go-90

  • #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
            Or just rent a cloud instance for a day?

            Comment


            • #7
              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


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

                Comment


                • #9
                  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


                  • #10
                    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

                    https://en.wikipedia.org/wiki/Ninety-ninety_rule
                    Last edited by amehaye; 12-19-2018, 03:20 AM.

                    Comment

                    Working...
                    X