Announcement

Collapse
No announcement yet.

ESR Switches To Threadripper But His GCC SVN-To-Git Conversion Could Still Take Months

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

  • #41
    (Or, worse yet, keep the commit history, but in a malformed state that will probably break git blames at some point in the future).
    Blame annotations exponentially[2] lose their importance over time. It's nice to see who committed a bug in Linux 2.6.13 (almost 14 years ago), but it is only making up 30%[1] (in 2010!) - and ever declining. So if blames are broken in some way, few will care.
    [1] https://lwn.net/Articles/374574/
    [2] Just not sure what kind of exp model it follows, e.g. importance(time)=1-exp(time) or importance(time)=k^time (for some 0<k<1) or something else. ;-)

    Comment


    • #42
      Doesn't all this beg the question if there are actually any (objectively good) competing efforts worth funding/backing over the ESR effort? If anything, friendly competition might get the ball rolling a bit faster?

      Can the effort lead by Linaro developer Maxim Kuvyrkov be classified as the only real competition at this stage?

      Comment


      • #43
        Originally posted by Terrablit View Post

        I think the project is useful, but not excessively so. It's going to be a massive repository, and lots of FOSS devs work on bandwidth-limited connections. There's over 30 years of commits there. And we could just keep the older history available for browsing. That said, we'd all still rather have the history converted than not. Especially recent commits that could be used for bisecting. But it's definitely not worth the time and effort invested in it. The timeline provides a lot of context. It's not just a few months.

        ESR offered his "help" converting the repository back in 2015-08-23. So it's been almost four years since he inserted himself into the process by negging all the existing options and praising his own expertise and tools. Check the GCC mailing list threads from May 2015. There's two relevant threads in the middle of that page: "Offer of help with move to git" and "Moving to git". Jason Merrill accepted that offer and delegated the task to ESR on 2015-08-27, which was when ESR ordered his extra 32GB of ram funded by Patreon subscribers for the machine I talked about earlier in the thread.



        There's an obvious reason why everyone's fed up with him over this. It's almost four years later and he's still not done passing the buck. And he's super casual about it not being done, too. Honestly, we could have had someone manually walk through SVN commit-by-commit and recommit the data to git and they would've been done already. But it's okay because there's a "65% chance" he can have it done by September. That sounds promising and all, but don't forget that ESR also said that it's "not high enough for me to make any hard promises."

        GCC members are still being way nice and respectful about him dragging the conversion down. Anonymous forum members? Not so much.

        Setting aside the ESR criticism for the moment, and keeping in mind I'm someone that's not dealt with git & svn more than in passing (still using CVS :P), why is it so important to move GCC from svn to git to begin with? It seems like the project is getting along just fine on svn as it is. If it's not broke, don't fix it. What's broke in svn that's so important that git fixes?

        Comment


        • #44
          Originally posted by stormcrow View Post
          Setting aside the ESR criticism for the moment, and keeping in mind I'm someone that's not dealt with git & svn more than in passing (still using CVS :P), why is it so important to move GCC from svn to git to begin with? It seems like the project is getting along just fine on svn as it is. If it's not broke, don't fix it. What's broke in svn that's so important that git fixes?
          SVN made branching really difficult, and it's a centralized version control system instead of a decentralized one. Both have good points, but the decentralized one is significantly better for teams where the members can be far away from each other, or might have limited internet access. Which is definitely the case for GCC and most other FOSS projects. With a DVCS, you make your changes locally and only worry about merging the commits in when your entire changeset is completed and ready for submission. You can make multiple small commits locally without fighting over files, and many people can work on the same project in a smoother fashion. Centralized ones require you to check out files, and there's file locking and stuff. Git's better about conflict resolution before adding in extra tools. If there's changes on the same file, you can rebase your changes and move quickly as long as the changes themselves don't conflict (like changing the same lines, or a change and a massive refactor).

          Comment


          • #45
            Originally posted by stormcrow View Post


            Setting aside the ESR criticism for the moment, and keeping in mind I'm someone that's not dealt with git & svn more than in passing (still using CVS :P), why is it so important to move GCC from svn to git to begin with? It seems like the project is getting along just fine on svn as it is. If it's not broke, don't fix it. What's broke in svn that's so important that git fixes?
            We still use SVN at work, and I see nothing in git that makes me want to switch, but that's because we have a centralized development model. Git really does make much more sense for OSS projects.

            Comment

            Working...
            X