17 ms·

WebKit on GitHub

• brnt 4y ago
  Could WebKit be a viable alternative to Blink, should Mozilla bite the dust?
  • JohnTHaller 4y ago
    Blink is a fork of WebKit. Apple manages WebKit development. Google manages Blink development.
    • no_way 4y ago
      It is a fork, but that was really long time ago, most parts of both engines were completely rewritten so for all intents and purposes these are completely different engines.
      • capableweb 4y ago
        Maybe not really long time ago, maybe around ten if I'm remembering correctly. But, maybe in web time, that's pretty long time ago.
      • filmgirlcw 4y ago
        They’ve splintered a ton over the years for sure, but there are still similarities. But yes, this isn’t like the first few years when Blink was just WebKit with V8. But on the whole, Blink is still more similar to WebKit than it is to Gecko.
  • aaaaaaaaaaab 4y ago
    1. Yes 2. No
    • olliej 4y ago
      right? We already have an IE-esque level of monopoly and associated behavior from chrome/blink. Making it just blink+webkit seems like it would be even worse - even though they have diverged significantly it's also wrong to think they're "different" in the sense of gecko and blink/webkit or even presto. I think the real problem is the gecko and spidermonkey seem to be falling significantly behind on real user experience. This is ignoring the Firefox application itself which I find super irksome. But as their gross built in tracking+advertising shows they are at least somewhat hurting for cash which does not help, and encourages gross stuff like said spam+tracking. It doesn't help that the google folk keep shoving out half-assed specs for whatever some google team has decided they want/need with specs but little thought of generally of how to make more universal solutions. That just means you've got constant pressure to implement ever increasing numbers of standards just to stay in place - if apple (and technically MS in the past) has difficulty keeping up with the constant "spec" spam it's hard to see Mozilla managing in the longer term.
  • vbezhenar 4y ago
    If that’s the same WebKit powering Safari, why not. It’s the second most popular browser after all.
    • brnt 4y ago
      AFAIK, Apples control over WebKit is not any less than Googles over Blink, which many say is the source of many of the webs problems. I remember the days Apple posted tarballs infrequently. I'm wondering if this move may open development up, and thus may become a codebase more widely 'owned' than Blink's.
      • GeekyBear 4y ago
        > Apples control over WebKit is not any less than Googles over Blink, which many say is the source of many of the webs problems I'd say that the issue with Google's control of web standards stem from their surveillance capitalism business model.
        • pdpi 4y ago
          Microsoft's stranglehold over the browser market was a pretty huge problem, irrespective of their business model. The web is way too important to be so tightly controlled by one single company, no matter who they may be.
          • GeekyBear 4y ago
            It isn't Microsoft that has entered the extinguish phase for ad blocking browser add-ons. I also don't remember Microsoft doing anything as anti-user as trying to keep pop-up blockers from working back in the bad old days.
            • olliej 4y ago
              Pop-ups were universally reviled, but also explorer aggressively pushed lots of random half features to support their products - the only difference is that they didn't publish a "spec" as google uses to create a veneer of not being anti-user. MS's anti-user was in the form of ensuring that necessary sites would not work in other browsers (including the Mac IE engine, whose name I have forgotten, and therefore IE mobile). They didn't block ad blockers, etc because they didn't support any kind of extensions :D
  • filmgirlcw 4y ago
    I mean, Blink is a fork of WebKit, so yes? But it’s also even less-responsive to upstream contributions so, outside of embedded systems that had previously adopted WebKit, I seriously doubt it'll recapture the traction it had before the fork.
    • Longhanks 4y ago
      "recapture the traction"? It is used by literally billions of devices of varying form factors every day. It has probably 100x the number of users as Gecko/Mozilla Firefox and one of the wealthiest companies on the planet sponsoring development, and I don't see Apple betting on Gecko or another fork of Chrome anytime soon.
      • filmgirlcw 4y ago
        Who said anything about Apple? I would never suggest Apple use another fork or the fork they incubated/created/developed. I was replying to a comment asking if WebKit, which != Safari could be a replacement for the Chrome-driven world we are in and when used by people who aren’t Apple. And yes, it is absolutely bigger than Gecko. No question. But are you going to tell me with a straight face that WebKit has the same amount of traction with third-parties as Blink? Because sorry, that’s not the case. That was the case for about 5 years, when post iPhone, everyone and their brother decided to use WebKit to power their mobile browser for whatever mobile OS they were building for (Android, BlackBerry, Symbian/Maemo/Meego, webOS, Tizen) or for whatever embedded systems they were designing for in-car systems or whatever, but after the Google fork became demonstrably different, the surviving players in that arena switched to Blink because Google was faster at iterating and easier to work with for upstream commits (easier does not mean easy).
  • pipeline_peak 4y ago
    Apple has iOS browser control on complete lockdown, so even if it performed as bad as Gecko, they’re pretty well off. > bite the dust If I were ceo of Mozilla I would have cut off Firefox development like 5 years ago. It doesn’t look pretty, but AOL and Yahoo changed assets, they don’t look as ugly. But I also hate a lot of what they currently stand for, and they don’t really have assets. They’re like some NPR for web standards documentation, and while it is the best, it’s not very valuable. Google seems to have a lot of leading control while Mozilla is angry outside, with a megaphone, and red-orange dyed hair. They’ve always been open source, they’ll die of natural causes.
    • sgjohnson 4y ago
      > But I also hate a lot of what they currently stand for. What exactly out of this this you hate so much? https://foundation.mozilla.org/en/advocacy/ https://foundation.mozilla.org/en/advocacy/
      • pipeline_peak 4y ago
        lol so much noise, if this is a browser dev company, they're no better than I am on HN right now during work hours.
        • sgjohnson 4y ago
          But it’s far more than a browser dev company, and the Mozilla Foundation is a non-profit entity.
          • pipeline_peak 4y ago
            I guess, I hate to be more pessimistic than I already am, but when I see pointless petitions to “Facebook: Stop Group Recommendations” I don’t see anyone over there truly “fighting the good fight”. I think GNU is a far better example of this type of action. I think an open source foundation has to stand on the shoulder of a valuable product to get noticed. GNU has all of its things, Mozilla is an acoustic guitar busker playing “bulls on parade by Ratm” outside of a Barnes and Nobles.
  • kitsunesoba 4y ago
    Ideally, we need both Gecko and WebKit to be healthy, with additional promising alternatives on the horizon.
    • deleted 4y ago
      [deleted]
  • cwp 4y ago
    Sigh... apparently I'm old.
  • Cyberdog 4y ago
    What does Mozilla biting the dust have to do with WebKit being viable? And even if they did, I think Gecko has enough of a fan base that it would live on for a very long time. NetSurf and Dillo are still around after all.
    • fomine3 4y ago
      If Mozilla bite the dust, unfortunately Firefox/Gecko developers will lost the job, then possibly some of them start developing WebKit or based browser on Apple or different corp. I don't want it.
  • sph 4y ago
    Not any more viable than it is now. Brendan Eich IIRC said they looked into building Brave on top of Webkit but it was so hard to compile and embed across all three platforms that they went with Chromium. Same story with Gecko. So that's another reason why we now have a Blink monoculture: because the alternative engines didn't spend any effort in making them usable by third party applications.
    • deleted 4y ago
      [deleted]
    • pabs3 4y ago
      Hmm, WebKit is used by lots of apps on Linux these days; at least GNOME Web, GNOME evolution and Liferea.
      • sph 4y ago
        WebKit is used by the WebkitGtk library which all of these include. But it's been stagnating for years and it's still not a viable replacement for Gecko and Chromium (broken scrolling on scaled screens, WebAuthn is unsupported so I can't login to my email account, etc.) In any case, if I recall correctly Eich's comment, the biggest difficulty was building webkit for Windows. The documentation was very out of dated, and it's understandable given Apple's focus on its OS. Even this GitHub says it's a web engine for "macOS, iOS and Linux".
  • jacooper 4y ago
    Its the worst.
  • politelemon 4y ago
    It wouldn't unfortunately. It's merely one stranglehold in a duopoly; Blink and Webkit are controlled by their corporate overlords in their respective spheres of influence. Ios won't allow non-Safarized browsers (think back to the IE days, but worse), and Google decides what goes in Blink. So in short, no. If Mozilla dies, then there will be trouble and would need someone to carry on their work as the last remaining 'freedom' blessed engine.
• latchkey 4y ago
  As someone who was there in the very very early Subversion meetings, I'm surprised it took this long for them to migrate.
  • miohtama 4y ago
    What's a decade or two in the grand scale :)
    • samstave 4y ago
  • olliej 4y ago
    The Git dev model is _very_ different from cvs, svn, etc so the trade offs are less obvious. A lot of the benefit of git to me has always been the local development model, but the git-svn bridge made that largely transparent which I think lowered the pressure to change.
    • latchkey 4y ago
      > The Git dev model is _very_ different from cvs, svn, etc so the trade offs are less obvious. I think that the difference makes the tradeoffs using anything other than git, more obvious. I even held out myself for a very long time with svn vs. git and once I switched... I kicked myself for not doing so earlier. But, like they said in the post... they did need a feature, which is core to svn (incrementing changelog ids) and a workaround in git. Minor in the grand scheme of things.
  • bastardoperator 4y ago
    If they had floating or dynamic externals and a bunch of permission models, I'm not surprised at all. I'd label this more of a conversion versus a migration.
  • xtracto 4y ago
    I remember migrating some codebase from CVS to SVN ... and this was sometime after CVS was adopted instead of "at the end of the day, every dev will copy his change into a floppy disk and give it to the Tech Lead for merging". This was during the 90s in a software development company in Mexico. Good times!
• pipeline_peak 4y ago
  This is one of those things you don’t really want to announce. It’s best to quietly make the migration and sweep it under the rug.
  • ian-g 4y ago
    I mean, as far as annoucements go, it's a pretty quiet one. We did this. We chose the obvious host. We like ordering commits chronologically, we came up with something for that. Ok bye.
    • williamscales 4y ago
      Does Apple not have an internal department that handles this for all their teams? Seems kinda weird for a division of a company to even have to choose their host.
      • olliej 4y ago
        The Open-source projects generally do things separately - e.g. llvm, as you're otherwise requiring apple set up a new account system (blocking contributing on iCloud account would seem less great), and building up its own UI and infrastructure for a git interface. Also given that GitHub is a somewhat universally understood host that people seem to like, and it has all that UI/development integration that people like it kind of makes sense to just use that. It also seems that having GitHub accounts is increasingly widely spread so contributors would not necessarily have to create yet another account with yet another service.
        • deleted 4y ago
          [deleted]
    • pipeline_peak 4y ago
      Why risk anything at all, who outside webkit developers needs to know this? Idk how investors, or any powerful external entities think, but switching to Git in 2022 isn't net positive news. It may be a subtle announcement, but it made it's way onto the forum of a Startup generator / Investment fund.
• joemaller1 4y ago
  Curious to see how this affects contributions.
• olliej 4y ago
  Awwwww, I remember back in the days of dealing with CVS, where there was so much scripting to try and manage basic stuff we take for granted like creating patches that included new files. Subversion was so undeniably superior that everyone was super happy and instant. Git took much much longer as the complexity vs. the win was much more debatable to people, so it's interesting to see this finally happening - I will miss linearly increasing revision numbers though. Glad to see they're keeping with bugzilla though - for whatever reason I find the GitHub issue tracker super annoying. Presumably at least part of that is familiarity and/or change resistance :D
  • JohnTHaller 4y ago
    With the bugzilla issue tracker, they keep ownership.
    • olliej 4y ago
      What do you mean? (as in ownership of what I guess?)
  • a-dub 4y ago
    > Subversion was so undeniably superior that everyone was super happy and instant. Git took much much longer as the complexity vs. the win was much more debatable to people, so it's interesting to see this finally happening - I will miss linearly increasing revision numbers though. p4 and then git were easy sells for large projects. while subversion was faster than cvs with its local hidden copy, many operations were still dog slow as they'd scan the whole repository (this was often worked around by creating lots of small repositories with associated wrapper scripts). p4 and git on the other hand were designed to handle large trees with ease. so for something on the scale of an operating system, browser, or both... the difference in productivity was significant. (tens of minutes vs single digit seconds for basic operations)
  • usefulcat 4y ago
    I remember when CVS was the new hotness. I was on a team of 3 at the time (90s), and one of our members worked remotely, so the fact that it was actually usable over a dial up connection was a killer feature for us. Also pretty much anything was better than SourceSafe, which is what everybody else in the company was using.
• mnd999 4y ago
  • _rrnv 4y ago
    Subversion started in that phase so maybe they're just trying to delay the inevitable.
  • olliej 4y ago
    What do you mean? (Not facetious, I'm out of the loop on such matters - I thought it was still just git on the cli?)
    • avg_dev 4y ago
      https://sfconservancy.org/blog/2022/jun/30/give-up-github-launch/ https://sfconservancy.org/blog/2022/jun/30/give-up-github-la...
    • beermonster 4y ago
      I assumed it to mean, what with GH being owned by Microsoft, it’s now in the extinguish phase of EEE (embrace, extend, extinguish). Though if anything I think it’s in the extend phase.
      • mnd999 4y ago
        Yes, that was what I meant.
  • srvmshr 4y ago
    GitHub is a company & git is a core technology which is replacing Subversion for version control. FWIW, WebKit could have moved to Gitlab, Gitea or Bitbucket & still used git. Subversion & CVS's days are numbered - the writing was on the wall for many years
  • doodlesdev 4y ago
    They kept the bugzilla tracker and will probably not use any CI on GitHub meaning migrating out will be easy, so not much to worry really. Problem is when repos rely on GH issues, projects, actions, codespaces, etc. because then migrating out becomes an enormous task.
• sedeki 4y ago
  They mention that they'd ideally want a natural ordering on the commit hashes. Something to do with their zero-tolerence security policy. What's the background there? Why do they need a natural ordering?
  • nemetroid 4y ago
    Zero-tolerance performance policy. You can find the policy [1] by searching the web. And the hashes don't have to be ordered. 1: https://webkit.org/performance/ https://webkit.org/performance/
    • 0xfffafaCrash 4y ago
      I wonder if this policy, or the general mentality that produced it, is why webkit is so underdeveloped and widely reviled by devs compared to alternatives. Sounds like one can push in a security bug or performance increase that is fast because it is frankly completely broken, but wouldn’t be allowed to reverse the decision at least not without finding some alternative unrelated performance increase. Features or fixes that may obviously be worth an associated dip in performance can generally not be implemented. Under these conditions if I knew of ways to improve performance without adverse effect, as a developer I would sit on them instead of applying them because I would need a stockpile of reserves to apply in case of emergency to account for unrelated performance degrading changes that absolutely need to be made. I would also work to make sure the benchmarks were lousy and irrelevant. Policies like this can’t be written by people with any semblance of sense. Singular mindedness on one metric and extreme policies like this can kill development and subvert goals just as lack of discipline can. Everything is a balance. Weigh performance metrics heavily by all means, but absolutism leads to the absurd. I guess as long as Apple holds its monopoly on keeping iOS device browsers exclusively on Webkit, it will stick around though. Sadly having had years of an inside perspective on the competence level or lack thereof of decision makers in the non-revenue generating parts of their software business, can’t say this policy surprises me.
      • saagarjha 4y ago
        You wonder wrong.
• favorited 4y ago
  TIL about `git rev-list --count HEAD`. I've been spelling it `git rev-list HEAD | wc -l` for years.
  • jamal-kumar 4y ago
    Yeah I think that's one of those features that comes in handy when you're developing on Windows with git
    • favorited 4y ago
      Interesting – what makes it particularly handy on Windows? I've only used it for automating build numbers. The number of commits on the main branch behaves, in practice, close enough to a monotonically increasing counter that it works 99.9% of the time without anyone thinking about it.
      • klodolph 4y ago
        “Handy” because Windows doesn’t have the same set of utilities like wc.
        • cerved 4y ago
          in git for windows, wc is included
          • xfmpXIe76lF4GfR 4y ago
            Depending on which git distro you installed and what options you chose, sure.
            • fomine3 4y ago
              Generally Git for Windows includes bash and coreutils, but it's not work on cmd or PowerShell unless it's added to PATH, so it would be useful sometimes.
• tpoacher 4y ago
  The title on HN is a bit silly. Presumably they migrated from subversion to git. And then hosted their bare git repository Github to serve as their "central" repository. So, where was their svn repository hosted before this?
  • deleted 4y ago
    [deleted]
  • filmgirlcw 4y ago
    On their own SVN instance on WebKit.org (which is maintained by Apple)
• tolmasky 4y ago
  Funny story: my first task when I joined the original iPhone team was to merge our forked WebKit with master. It was a sort of hazing ritual slash "when else would we do it but when someone new joins?". Anyways, we used a tool called SVK[1] in order to get very primitive "git-like" abilities. It was basically a bunch of scripts that used SVN under the hood. For example, in order to get the "local everything"-style behaviors of git, the very first thing it did was checkout every single version of the repository in question. For WebKit, this meant that the first day was spent leaving the computer alone and letting it download for hours. I made the mistake of having a space somewhere in the path of the target folder, which broke something or other, so I ended up having to do it all over again. Anyways, I distinctly remember one of the instructions for merging WebKit in our internal wiki being something like "now type `svk merge`, but hit ctrl-c immediately after! You don't want to use the built-in merge, it'll break everything, but this is the only way to get a magic number that you can find stored in [some file] after the merge has started. If it's not there, try `svk merge` again and let it go a little longer than last time." A few hires later (I think possibly a year after) someone set up a git mirror internally to avoid having to do this craziness, which if I remember correctly, was treated with some skepticism. This was 2007, so why would we try some new-fangled git thing when we had svk? 1. https://wiki.c2.com/?SvkVersionControl https://wiki.c2.com/?SvkVersionControl
  • evmar 4y ago
    We had a similar rotation on Chrome team for merges from WebKit (pre fork), and it was similarly a lot of work and clunky tooling! A few times in my career (including this one) I have thought, "We are sure going to a lot of effort to maintain a modified copy of that code while also preserving our changes atop it as we sync, and this is exactly the kind of workflow that Git was designed to enable." Like, the Linux kernel dev workflow is all about different maintainers maintaining different branches and merging between them, and that is where Git comes from. So in a setting other than Chrome I have tried out using Git to try to manage these sorts of situation. I have found in practice many engineers aren't comfortable enough with Git to have it end up helping them out tooling-wise. This is disappointing but also not too unexpected given Git's UI.
    • 4y ago
• tiffanyh 4y ago
  License? Maybe I just can't find it but what's the license used for Webkit? It doesn't appear in the repo.
  • monkin 4y ago
    https://webkit.org/licensing-webkit/ https://webkit.org/licensing-webkit/
  • stcont 4y ago
    BSD for some, LGPL v 2 for the rest.
  • nailer 4y ago
    Webkit is a fork of KHTML so presumably restricted (not not) by whatever the open source license KHTML license allows.
  • deleted 4y ago
    [deleted]
• nimbius 4y ago
  github has had more than fifty outages this year alone, and has a rocky history of recourselessly banning users from countries that are sanctioned by the United States. switching to github makes no sense if "The WebKit project is interested in contributions and feedback from developers around the world." https://www.githubstatus.com/ https://www.githubstatus.com/ who made this decision?
  • klodolph 4y ago
    I think the bigger picture here is the migration to Git, since that lets you keep working during an outage. SVN does not.
    • lapinot 4y ago
      > I think the bigger picture here is the migration to Git Is it tho? Why wouldn't they just install git on their server? Now there is not many mainstream successful social hosting for svn. They acknowledge the choice of github is to attract devs. So it's as much about the software as about the type of hosting and web presence.
      • acdha 4y ago
        > Why wouldn't they just install git on their server? That's easy, and it's about 5% of the functionality which GitHub provides. Even if you're working entirely in private, the tools you'd have to build yourself to do code review, CI/CD, package management, security updates, etc. are a significant amount of work and that's before you get to things like Codespaces.
        • the_gipsy 4y ago
          I doubt webkit would do anything beyond code review on github.
          • acdha 4y ago
            Code review itself is a big deal in terms of the complexity of the UI for managing reviews but I’d also be surprised if they didn’t use anything else. Linting and other static analysis checks, reporting CI results, etc. are quite powerful and less work than setting the equivalent infrastructure up yourself.
• tibbydudeza 4y ago
  What does Apple use for source control ???. I know Google is all custom and MS uses (???) a modified instance of Perforce.
  • bragr 4y ago
    Microsoft maintains the entire Windows source tree in Git now and has made some really interesting contributions to git where it comes to very large projects, though I don't know about the penetration throughout other dev groups. They also own Github now obviously.
    • caycep 4y ago
      was this before or after the github acquisition? I figure if they were going to spend the money for github they probably intend for git to have a bigger role
      • dark-star 4y ago
        long before
      • deleted 4y ago
        [deleted]
      • WorldMaker 4y ago
        Microsoft started the Windows transition to git sometime before Github acquisition as a part of a company-wide effort to move to VSTS/Azure DevOps Repos internal dogfooding. The choice there was between the zombie ghost of TFS source control or git, so you can possibly imagine some of the reasons why they chose to put a lot of time/effort into making git work for themselves. The subsequent acquisition of Github seems to have made them even happier at the switch to git.
    • modeless 4y ago
      I was just looking at Microsoft's git VFS (https://github.com/microsoft/VFSForGit https://github.com/microsoft/VFSForGit), which is deprecated and now points to Scalar (https://github.com/microsoft/scalar https://github.com/microsoft/scalar), which is also deprecated I think? What's Microsoft's story with git for large repos now? Is there still a virtual file system involved at all?
• doe88 4y ago
  Is there a reason why it seems there is so little documentation/comments in source files of WebKit? Or maybe I'm missing something/opened the wrong files.
  • mnutt 4y ago
    Documentation has been a bit of a challenge in my experience. There are some high-level docs at https://trac.webkit.org/wiki https://trac.webkit.org/wiki though many are 10-15 years old at this point. My approach has been to look at the commit history for the file to see if the changesets shed any light, and sometimes go to the attached bugzilla link to see if there was any discussion about the change there. Then attach a debugger and step through to try to uncover how the classes relate to one another.
  • tuankiet65 4y ago
    You aren't opening the wrong file, there isn't much documentation in WebKit besides a few Markdown files. I'm not sure why this is the case.
  • saagarjha 4y ago
    Most WebKit developers are good at documentation, it’s just that they often work on things that their employer would not like being made obvious because it deals with SPI or unreleased products or security vulnerabilities. Commit messages are actually pretty good for the most part except in these situations where a laconic or purposefully misleading message will be used.
  • domenicd 4y ago
    There's some policy about comments being bad / code should be self documenting. From what I hear from my colleagues on the Chrome team, one of the first things they were delighted to do after forking Blink was to finally go around and comment the various confusing parts of the codebase. (And, no longer get requests to remove comments when trying to land a PR.)
    • habosa 4y ago
      I've met some very smart and capable programmers who perpetuate this "style". It's so harmful. Comments are good for the writer AND the reader.
• aendruk 4y ago
  That’s a hefty repository if all you want [1] is part of it. Subversion offers a way to download just a subdirectory; is there an analogous solution for Git? [1]: https://github.com/HimbeersaftLP/ios-safari-remote-debug-kit/blob/bfa15e7/src/generate.sh#L16-L19 https://github.com/HimbeersaftLP/ios-safari-remote-debug-kit...
  • a_t48 4y ago
    `git subtree` but it might still download the whole history
    • cerved 4y ago
      subtree is for extracting / pulling a subtree, a different problem
      • a_t48 4y ago
        Is a sub tree not a folder? I recall using it before for syncing subsets or another repo.
  • gman83 4y ago
    sparse-checkout -- https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout/ https://github.blog/2020-01-17-bring-your-monorepo-down-to-s...
    • cerved 4y ago
      no, that's still a full download, just the checkout is sparse
  • notriddle 4y ago
    GitHub does: https://docs.github.com/en/get-started/importing-your-projects-to-github/working-with-subversion-on-github/support-for-subversion-clients https://docs.github.com/en/get-started/importing-your-projec...
  • 4y ago
• lxe 4y ago
  > git’s distributed nature makes it easy for not just multiple developers, but multiple organizations to collaborate on a single project. Git is as "distributed" as Ethereum at this point. You have a central repo on github onto which you push changes. Just because you have a copy of the main branch when you're working on stuff, it's no different from SVN. Yes it has the capability to be distributed, and individual contributors can certainly host their own git servers and you can have as many remotes as there are contributors, but we aren't doing things this way are we?
  • simonw 4y ago
    I think the point here is that you ARE doing things that way if you are multiple companies collaborating on something at the scale of WebKit.
  • ipaddr 4y ago
    You are seeing the tip of the iceburg. The most discoverable online platform is github and others exist at much smaller numbers. Because these are public they are easy to see and count. Private instances are hidden by default which makes them hard to count.
  • samatman 4y ago
    This is the kind of thing you say when you've never worked with a centralized version control system before, because if you had, you wouldn't.
• aledalgrande 4y ago
  wow can't imagine a large repo on svn... branching and merging must have been a nightmare. though git-svn brings back sweet, fuzzy memories...
• 5350-uiop-1130 4y ago
  I love svn, it puts some constraints on other non technical people. That makes my life easier.
  • colordrops 4y ago
    Could you be more specific?
    • 5350-uiop-1130 4y ago
      - it's more difficult to do "agile", churning out lots of code, working simultaneously on the same pages, or functions between different teams, which then needs to be merged together by some unfortunate (possibly clueless) dev. it puts a restraint on ignorant management who don't appreciate downstream issues. - merging and branch maintenance is more rigid with svn, so teams tend to have dedicated release teams to handles this, instead of offloading this onto devs - most devs now are expected to handle git merging and so on, not so with svn. i worked about 10 years with svn, and 5 with git, and just my exp only of course.