Announcement

Collapse
No announcement yet.

GCC's Conversion To Git Is Still Turning Out To Be A Massive Headache

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

  • GCC's Conversion To Git Is Still Turning Out To Be A Massive Headache

    Phoronix: GCC's Conversion To Git Is Still Turning Out To Be A Massive Headache

    Remember earlier this month when GCC's long in the works conversion from SVN to Git was being held up by the lack of RAM on Eric S Raymond's system? Well, it turns out that's just part of the problem...

    http://www.phoronix.com/scan.php?pag...t-Complexities

  • #2
    At this stage it's probably best to take a modern development version of GCC and set it up as the initial seed of a GIT repository while ignoring all the older stuff that can go into legacy mode with SVN. Just get one correct version into GIT and start from there without worrying about making the GIT repo act as the historic archive for all of GCC.

    Comment


    • #3
      Originally posted by chuckula View Post
      At this stage it's probably best to take a modern development version of GCC and set it up as the initial seed of a GIT repository while ignoring all the older stuff that can go into legacy mode with SVN. Just get one correct version into GIT and start from there without worrying about making the GIT repo act as the historic archive for all of GCC.
      The motivation for having at least some modern backhistory on master/trunk and maintained branches is for still being able to easily bisect regressions without having to switch back over to SVN for doing any bisects beyond the initial commit.
      Michael Larabel
      http://www.michaellarabel.com/

      Comment


      • #4
        Originally posted by Michael View Post

        The motivation for having at least some modern backhistory on master/trunk and maintained branches is for still being able to easily bisect regressions without having to switch back over to SVN for doing any bisects beyond the initial commit.
        Well, perhaps things work if they contrain themselves to ~10 years of history, instead of all.. emm. 30? years of history.

        Comment


        • #5
          Meanwhile KDE folks converted all their svn repos to git ages ago with their own https://github.com/svn-all-fast-export/svn2git
          Perhaps mr Raymonds should stop reinventing the wheel?

          Comment


          • #6
            Originally posted by reavertm View Post
            Meanwhile KDE folks converted all their svn repos to git ages ago with their own https://github.com/svn-all-fast-export/svn2git
            Perhaps mr Raymonds should stop reinventing the wheel?
            I don't think that's comparing like for like, KDE was mostly small repositories in comparison to GCC, the feature work was also much bigger branch merges than would have been seen in GCC

            Comment


            • #7
              It's rather surprising that to this day, noone has come up with a reliable and scalable conversion tool between 2 such mainstream VCSes.

              Comment


              • #8
                Originally posted by anarki2 View Post
                It's rather surprising that to this day, noone has come up with a reliable and scalable conversion tool between 2 such mainstream VCSes.
                It's not that bad if you don't care about doing intensive surgery on your repo. SVN trunk maps with Git master, SVN has arbitrary paths but sensible people use strict branch and tag semantics with SVN which can be translated into Git with ease. From DCVS to another it's most likely even easier

                Comment


                • #9
                  I still don't understand why this is a performance problem. Is he trying to do some kind of live conversion without taking the repository offline? I.e. still accepting new commits while the conversion is in process? We can brute force RC5-64 searching 15,769,938,165,961,326,592 keys for a solution, but we don't have the computational power to migrate some code from one server to another?

                  Comment


                  • #10
                    Originally posted by anarki2 View Post
                    It's rather surprising that to this day, noone has come up with a reliable and scalable conversion tool between 2 such mainstream VCSes.
                    The problem seems to be oddities in their SVN repo, and it's the repair tool that's taking up the RAM.

                    Comment

                    Working...
                    X