Announcement

Collapse
No announcement yet.

A Linaro Developer Has Taken Up The Effort Of Converting GCC's SVN To Git

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

  • #31
    Originally posted by tuxd3v View Post

    No thanks,
    But I kindly offer you, the same amount you offered me..
    How nice, but you know I can't accept, I made it for you and I urge you to take it.

    Comment


    • #32
      Originally posted by RomuloP View Post
      I never converted a repository with millions of lines and 100 000 more commits so I really cannot tell if a 300 line script can do the job cleanly, by giving a look at git-svn source, I guess not, also it appears to ignore most of SVN properties. Anyway, we do not know what exactly are their needs.
      Because i was sick and tired of the svn nonsense of a customer, and because i am so dependent on git to give me information on why a given choice was made (which is mostly futile in an embedded shop), i went and scripted a partial conversion of the linux/bitbake relevant bits of 70GB worth of svn repositories. They used 3 repositories, with all projects spread all over mostly one of the relevant repositories, endlessly committing tool tarballs, and build results.

      There's all sorts of things that svn allows you to do:
      * branches are kind of filesystem based and do not have to happen in the repository root (and therefore do not need to be global).
      * merges are an afterthought and are properties which are not always adhered to, some big commits might be merges, some merges might be attempts to emulate cherry picks, etc.
      * svn externals are fun, especially since they can reference paths and (pseudo)branches in the same repository.

      Then there is the fact that GUIs like tortoiseSVN are popular, and a lack of knowledge of the underlying VCS of course leads to a lot of random button clicking.

      As for doing a solid conversion:
      * You can do large swathes of a conversion automatically, even in the worst case scenarios.
      * You should never strive to do a full conversion in one pass, and you should have the ability to continue where you last ran into an issue.
      * You will have to have some configuration in like yaml to allow you to easily, and repeatedly (in case things need to be redone), specify how to work around very specific issues with specific revisions after you've done the archeological work and decided what the right course of action is for a given revision.
      * You have to spend a lot of time talking to stakeholders as to what they want the end result to look like, and/or provide different options (git is easy that way though).
      * You cannot expect a singular svn repository to turn into a singular git repository. You are there to preserve code history of individual bits of code, and not to preserve a full repository, if you lose track of that, you're lost forever.
      * You might want to make a temporary cut to allow work to continue, and first convert the last 5ys or so, to allow people to test out the new workflow, and make up their minds, and provide the full _code_ history later (and do a rebase, which breaks peoples git repos, but that is a communication issue).

      While valiant, the ESR conversion toolset smells like a generalist trying to develop a general tool for all repository needs for all of humanity, losing track of the real goal. The ram complaint seemed weird, as you can trade speed for cost here, but it probably is borne from a lack of funds and a lack of even half-decent hardware. Reposurgeon also does not deal with funky things like externals.

      Comment


      • #33
        Originally posted by starshipeleven View Post
        How nice, but you know I can't accept, I made it for you and I urge you to take it.
        I advise you to grow a little bit, I mean, been more adult, mature..

        Comment


        • #34
          Originally posted by RomuloP View Post
          I never converted a repository with millions of lines and 100 000 more commits so I really cannot tell if a 300 line script can do the job cleanly, by giving a look at git-svn source, I guess not, also it appears to ignore most of SVN properties. Anyway, we do not know what exactly are their needs.
          That is true, but its also true, that people usually tries to complicate..
          That happens a lot in Databases.. translating a BD from big endian to litle endian difference hardware different os, different database versions and midlewares..

          I saw already big changes in midlewares, that were 4 years to be updated( some even more ), because in the process..people start "looping"...I need a tool to help in another tool, that needs another tools, that...
          It happened to me in 2014, I went to do a massive migration, that was stuck for more than 4 years, because not even the Company that Develops the MidleWare was able to Migrate it!!
          They took 8 months trying..in this process several companies were hired and also failed..
          I got in, the General Director told me "look, I know its not your fault, but we are trying for more than 4 years to Migrate, then I give you 6 months to Migrate..."

          I worked around 16 hours a day, in the weekends some hours too,after six months, 18TB of data were Migrated successfully!
          Everything were working as expected, there were documented minor changes, impossible to Migrate, because of so big Jumps in Versions, but no property was lost, not even at index numbers in databases tables, clean..

          This because I tried not to start looping, and using the Simplicity process..
          This Job Was for the Central Regulator of Cummunications in a Country, that I worked for..

          Long Story Short...people sometimes loose focus..

          Comment


          • #35
            Originally posted by tuxd3v View Post
            I advise you to grow a little bit, I mean, been more adult, mature..
            I advise you to stop posting troll bullshit about systemd in unrelated threads.

            Comment


            • #36
              Originally posted by tuxd3v View Post

              That is true, but its also true, that people usually tries to complicate..
              That happens a lot in Databases.. translating a BD from big endian to litle endian difference hardware different os, different database versions and midlewares..

              I saw already big changes in midlewares, that were 4 years to be updated( some even more ), because in the process..people start "looping"...I need a tool to help in another tool, that needs another tools, that...
              It happened to me in 2014, I went to do a massive migration, that was stuck for more than 4 years, because not even the Company that Develops the MidleWare was able to Migrate it!!
              They took 8 months trying..in this process several companies were hired and also failed..
              I got in, the General Director told me "look, I know its not your fault, but we are trying for more than 4 years to Migrate, then I give you 6 months to Migrate..."

              I worked around 16 hours a day, in the weekends some hours too,after six months, 18TB of data were Migrated successfully!
              Everything were working as expected, there were documented minor changes, impossible to Migrate, because of so big Jumps in Versions, but no property was lost, not even at index numbers in databases tables, clean..

              This because I tried not to start looping, and using the Simplicity process..
              This Job Was for the Central Regulator of Cummunications in a Country, that I worked for..

              Long Story Short...people sometimes loose focus..
              Sure you are right, but my point is, honestly it matters to ESR? I'm pretty sure it was not developed to port specifically GCC, and probably served well many conversions out there, even to ESR, To my guess ESR just do not want do waste time doing another blob for this because it is boring. I cannot see the "hard way" for ESR here, and sure I understand you, some of us have milestone or really need things done. Anyway he was right someone else will/need to do it.

              Comment


              • #37
                Originally posted by RomuloP View Post
                To my guess ESR just do not want do waste time doing another blob for this because it is boring. I cannot see the "hard way" for ESR here, and sure I understand you, some of us have milestone or really need things done. Anyway he was right someone else will/need to do it.
                Totally Agree with you..
                This processes could be boring, or more than boring..
                If you have pressure above you with timelines, regular meetings with the big boss and so on, ...it could even asphyxiate you..an hard-attack is not difficult to imagine in those scenarios..

                He probably took some approach, and in the process he discovered something better, a better algorithm or something else, so recreate something, that then needs to be adjusted with another parts, and then he discovered something else..and this process starts again...

                I bet this all, are a way for him to continue to maintain his code practices, in his spare time, or something...
                Any one has its pet projects,
                This could be the case too, I don't doubt that he will have a nice tool, if he continues pursuing the Nirvana state.

                Comment


                • #38
                  Mr ESR should probably throw away marketing BS and his crap code. Honestly, when someone reaches similar feat with "The scripts? Less than 300 lines of Bash leveraging the Git and SVN utilities" it just shows how to do things right. And ESR showcased us how awful it could look when it comes to enterprise crap and hype driven development. I bet Maxim's things also do not needs over 9000 gigz RAM, etc . Shame on ESR for sabotaging project for a while and showcasing how NOT to write your programs.
                  Last edited by SystemCrasher; 17 May 2019, 07:35 PM.

                  Comment

                  Working...
                  X