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

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


    • #12
      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 not agree more.
      I see very little point in keeping the entire history in comparison to the apparent drawback.
      At what point do you stop dragging around all your history in one repo? Forever? That'd be ridiculous.
      I'd split it, just as you are suggesting. I find it the only sane option.
      To much luggage does not make anyone happy.

      To me, this looks more like a crusade than a reasonable move.

      Comment


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

        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?
        I'm having a hard time believing that those 8 languages and 21 architectures are ones that are currently being supported.

        As for why the move should be done within any reasonable time frame, it's probably for the same reason they're moving away from SVN in general. SVN is very widely considered an inferior tool to Git and in many places considered as being only just better than no dedicated source control tool and an all round awful tool. Worse yet, most of it's use is considered to come from people who don't know better and projects that adopted before superior alternatives like Git and Mercurial came out.

        Originally posted by cybertraveler View Post
        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
        How often do you actually need to go back beyond what a drastically cut down Git transfer can go? Michael to my knowledge hasn't even gone back a full year in his bug tracking and you could probably easily lop off everything up to a couple of years ago on the GCC SVN.

        How often do you really need to go back more than a couple of years to track down a bug? Because the massive size of the GCC SVN history stems not just from the complexity of the project, but that the project has been managed on SVN since very early in the 2000s. We're talking about a full revision history going back a decade and a half for a very active project.
        Last edited by L_A_G; 12-18-2018, 06:07 PM.
        "Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."

        Comment


        • #14
          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.
          history is needed in one place, though obviously you can edit history in git, so you can do 1) start clean git history 2) slowly migrate svn to git 3) quickly do git filter-branch. forks will have to do some work after rewrite, though

          Comment


          • #15
            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).
            he is not a gcc dev

            Comment


            • #16
              there is a language with full control over memory usage and speed, but it requires good developer and esr isn't one.
              i wonder why go rewrite brought speedup of 3x-4x instead of expected 40x. is it go's fail or implementer's ?
              Last edited by pal666; 12-18-2018, 11:13 PM.

              Comment


              • #17
                The funny thing is that what ESR does is still more productive than anything written here.

                Comment


                • #18
                  Originally posted by milkylainen View Post

                  Could not agree more.
                  I see very little point in keeping the entire history in comparison to the apparent drawback.
                  At what point do you stop dragging around all your history in one repo? Forever? That'd be ridiculous.
                  I'd split it, just as you are suggesting. I find it the only sane option.
                  To much luggage does not make anyone happy.

                  To me, this looks more like a crusade than a reasonable move.
                  It's totally worth it. Have you ever worked on a large old code base? The people who know why things were done a certain way are gone, the history is all you have to go off.

                  Comment


                  • #19
                    Originally posted by L_A_G View Post
                    I'm having a hard time believing that those 8 languages and 21 architectures are ones that are currently being supported.

                    As for why the move should be done within any reasonable time frame, it's probably for the same reason they're moving away from SVN in general. SVN is very widely considered an inferior tool to Git and in many places considered as being only just better than no dedicated source control tool and an all round awful tool. Worse yet, most of it's use is considered to come from people who don't know better and projects that adopted before superior alternatives like Git and Mercurial came out.
                    Currently: C, C++, Objective-C, Objective-C++, Java, Fortran, Ada, and Go. That's 8. And they have variants in the standards (ex C89, C99, C11, C18). For the architectures, I'll let you do the research.

                    Good code doesn't rot. Banks still run the same Fortran code that they did in the 80's, just on larger mainframes.

                    I maintain my original comments about reposurgeon. It's worth the wait.

                    Comment


                    • #20
                      By the time he finishes, git itself will have been superseded by something with a much superior design. Possibly pijul.

                      Comment

                      Working...
                      X