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


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


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


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


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


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

              Comment


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


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


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

                    Comment


                    • #20
                      Originally posted by AndyChow View Post
                      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.
                      You do realize that C/C++ and Objective-C/C++ are really just base languages with an extended variant? They don't count as two separate languages. Also, the developers finished completely nuking GCJ (Java) from the codebase over two years ago, which kind of questions on your research on the subject.

                      Good code doesn't rot. Banks still run the same Fortran code that they did in the 80's, just on larger mainframes.
                      At what point did I claim anything to the contrary? Because the issue here was a major project sticking to a bad tool because they want to keep in a decade and a half of version history for the very rare occasions they need to go back more than a couple of years to track down bugs.

                      Also, the reason why you still see banks running their old mainframes with Fortran code is the cost of not only moving to something more maintainable, but also the rather extreme consequences of potential business interruptions as they move to something more maintainable. However the reality is that these systems will all have to simple be retired or moved to something more modern for the simple reason that most of the people with the skills necessary to maintain them have retired years ago.

                      It really doesn't matter how well you document your code when there's nobody with the specific skills necessary to pick up where you left...
                      Last edited by L_A_G; 12-19-2018, 05:48 AM.
                      "Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."

                      Comment

                      Working...
                      X