[HN Gopher] WebKit on GitHub
       ___________________________________________________________________
        
       WebKit on GitHub
        
       Author : miohtama
       Score  : 212 points
       Date   : 2022-08-31 20:03 UTC (2 hours ago)
        
 (HTM) web link (webkit.org)
 (TXT) w3m dump (webkit.org)
        
       | doe88 wrote:
       | 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 wrote:
         | Documentation has been a bit of a challenge in my experience.
         | There are some high-level docs at 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 wrote:
         | 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 wrote:
         | 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.
        
       | favorited wrote:
       | TIL about `git rev-list --count HEAD`. I've been spelling it `git
       | rev-list HEAD | wc -l` for years.
        
         | jamal-kumar wrote:
         | Yeah I think that's one of those features that comes in handy
         | when you're developing on Windows with git
        
           | favorited wrote:
           | 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 wrote:
             | "Handy" because Windows doesn't have the same set of
             | utilities like wc.
        
               | cerved wrote:
               | in git for windows, wc is included
        
               | xfmpXIe76lF4GfR wrote:
               | Depending on which git distro you installed and what
               | options you chose, sure.
        
       | tiffanyh wrote:
       | License?
       | 
       | Maybe I just can't find it but what's the license used for
       | Webkit? It doesn't appear in the repo.
        
         | cxr wrote:
         | > License? [...] It doesn't appear in the repo.
         | 
         | Wrong. There are copyright notices and license terms at the top
         | of every noteworthy file that contains substantial code.
        
         | stcont wrote:
         | BSD for some, LGPL v 2 for the rest.
        
         | nailer wrote:
         | Webkit is a fork of KHTML so presumably restricted (not not) by
         | whatever the open source license KHTML license allows.
        
       | sedeki wrote:
       | 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?
        
         | anderskaseorg wrote:
         | Git already has an ordering like this built in as 'git
         | describe'.
         | 
         | https://git-scm.com/docs/git-describe                   $ git
         | describe 593a2a5d0639b4b4f91ff6e6ffb64e72020f8fd8
         | v2.34.1-83-g593a2a5d06
         | 
         | This commit is 83 commits after the v2.34.1 tag. Git accepts
         | this identifier anywhere it would accept a commit hash, e.g.:
         | $ git log v2.34.1-83-g593a2a5d06         $ git show
         | v2.34.1-83-g593a2a5d06:branch.c
         | 
         | https://git.kernel.org/pub/scm/git/git.git/commit/?id=v2.34....
        
           | cerved wrote:
           | they want a global, presumably centralized, order
        
         | Trufa wrote:
         | I have literally 0 inside knowledge but from the article it
         | seems to be a more human visual thing than a software problem,
         | something like this was working in 12 and broken in 13 is a
         | more obvious regression than this was working in aaab131 and
         | broken in ccad53s
        
           | LeifCarrotson wrote:
           | 13 being greater than 12 is not a property that's just for
           | human vision. In Subversion a commit on a branch increments
           | the _global_ commit number.
           | 
           | Git doesn't have a concept of one commit being before or
           | after another once you've branched, or any native mechanism
           | for enforcing global state across branches.
        
           | mattkrause wrote:
           | Sequential IDs also let you think about ranges: a feature was
           | introduced in 11, broke in 17-23, and worked thereafter.
           | 
           | I used SVN like this in grad school: data files included the
           | SVN $Id$ of the script that generated them. This let you work
           | around bugs and experimental changes. For example, you might
           | hardcode a delay, realize it should be longer, and then
           | eventually decide to let the experimenter adjust it on the
           | fly. This is easy with sequential ids:                  if
           | version < 11:           delay = 50        elif 11 <= version
           | < 29:            delay = 100        else           delay =
           | params.delay
           | 
           | Using git hashes, you'd need to maintain an exhaustive list
           | of every version ever run, which is even tricker because
           | there isn't a sole source of truth like an SVN repo.
        
             | cerved wrote:
             | I must be missing something because this seems odd, why
             | isn't this code just different in each corresponding
             | version?
        
               | mattkrause wrote:
               | The SVN-controlled code _generated_ data by controlling
               | hardware and embedded the $Id$ of the controlling script
               | in its output. I would then refer to the version ID
               | later, when loading that data in for _analysis_. This
               | accounted for any changes to the data-generating code.
               | 
               | Sometimes these were bugs. For example, we tracked the
               | orientation and direction of objects moving on a screen.
               | One update redefined 0deg to be up/north/12:00 instead of
               | the +x direction used before. The code which loaded these
               | files checked the $Id$ value and rotated the directional
               | data so that the entire dataset used the same definition.
        
             | xfmpXIe76lF4GfR wrote:
             | Git also lets you think about ranges. You just tell it the
             | range and it figures out what commits are in the range. You
             | can also get a sequential number from whatever point you
             | choose with tools like `git describe`.
        
         | tln wrote:
         | "zero-tolerance performance regression policy"... no patch can
         | land if it regresses benchmarked performance.
         | 
         | I'm guessing the tooling around this used subversion's
         | increasing commit numbers and it was easier to add a shim to
         | git, than to rewrite or rethink the tooling.
        
           | usefulcat wrote:
           | > no patch can land if it regresses benchmarked performance
           | 
           | ..unless it fixes some important security vulnerability, one
           | hopes..
        
             | mhh__ wrote:
             | the trick is to change the benchmark at the same time
        
             | btown wrote:
             | Via https://webkit.org/performance/ :
             | 
             | > If a patch lands that regresses performance according to
             | our benchmarks, then the person responsible must either
             | back the patch out of the tree or drop everything
             | immediately and fix the regression.
             | 
             | I imagine that a security hotfix would lead almost
             | immediately to the second situation (perhaps as soon as the
             | implementor had gotten some sleep!)
        
           | xfmpXIe76lF4GfR wrote:
           | git literally has built-in tooling for this. It's called
           | bisect (and they literally mention "bisection" in the next
           | sentence).
        
         | nemetroid wrote:
         | 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/
        
       | brnt wrote:
       | Could WebKit be a viable alternative to Blink, should Mozilla
       | bite the dust?
        
         | cwp wrote:
         | Sigh... apparently I'm old.
        
         | pipeline_peak wrote:
         | 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 wrote:
           | > 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/
        
             | pipeline_peak wrote:
             | 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 wrote:
               | But it's far more than a browser dev company, and the
               | Mozilla Foundation is a non-profit entity.
        
               | pipeline_peak wrote:
               | 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.
        
             | ThunderSizzle wrote:
             | Mozilla: A healthy internet requires an active, global
             | community.
             | 
             | Also Mozilla: We need more than deplatforming [of those we
             | disagree with and already attempted to deplatform]
        
             | Dalewyn wrote:
             | Personally? All of it.
             | 
             | None of Mozilla's virtue signalling serves to bring back
             | the Firefox of yore. Firefox has instead followed Chrome's
             | heels at every turn to the point I might as well just use
             | the real deal rather than a third-rate knock off.
             | 
             | I want a lean, effective browser that I can tailor to my
             | specific needs and desires, and Firefox has been not that
             | for at least 20 years.
             | 
             | Mozilla is (supposed to be) a collective of computer
             | programmers, not activists and lobbyists. So fuck their
             | advocacy, more accurately virtue signalling. All of it. The
             | specifics don't matter. Fuck all of that noise. If they go
             | back to making some good software I might be more
             | supportive and respectful of them again, but not a step
             | before.
        
         | Cyberdog wrote:
         | 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.
        
         | JohnTHaller wrote:
         | Blink is a fork of WebKit. Apple manages WebKit development.
         | Google manages Blink development.
        
           | no_way wrote:
           | 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.
        
             | filmgirlcw wrote:
             | 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.
        
             | capableweb wrote:
             | 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.
        
         | kitsunesoba wrote:
         | Ideally, we need both Gecko and WebKit to be healthy, with
         | additional promising alternatives on the horizon.
        
           | [deleted]
        
         | aaaaaaaaaaab wrote:
         | 1. Yes
         | 
         | 2. No
        
           | olliej wrote:
           | 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.
        
         | sph wrote:
         | 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.
        
         | vbezhenar wrote:
         | If that's the same WebKit powering Safari, why not. It's the
         | second most popular browser after all.
        
           | itslennysfault wrote:
           | It's also the worst browser and the bane of every developers
           | existence. It's legit the new IE.
        
           | brnt wrote:
           | 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.
        
             | babypuncher wrote:
             | The problem with Blink is not necessarily that Google
             | controls it, the problem is that Blink owns the lion's
             | share of the browser market. This makes Google's control of
             | Blink a problem, since it effectively means Google controls
             | the lion's share of the browser market.
        
             | GeekyBear wrote:
             | > 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 wrote:
               | 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.
        
               | Tijdreiziger wrote:
               | Microsoft's business model was 'we need to deal with
               | Netscape before the Web kicks our ass' followed by 'we
               | own the market now, no need to spend resources improving
               | this'.
               | 
               | Of course, Firefox and later Chrome came around, so in
               | the end the Web kicked Microsoft's ass anyway.
        
               | GeekyBear wrote:
               | 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.
        
         | filmgirlcw wrote:
         | 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.
        
       | tpoacher wrote:
       | 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]
        
         | filmgirlcw wrote:
         | On their own SVN instance on WebKit.org (which is maintained by
         | Apple)
        
       | latchkey wrote:
       | As someone who was there in the very very early Subversion
       | meetings, I'm surprised it took this long for them to migrate.
        
         | bastardoperator wrote:
         | 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 wrote:
         | 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!
        
         | miohtama wrote:
         | What's a decade or two in the grand scale :)
        
         | olliej wrote:
         | 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 wrote:
           | > 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.
        
       | pipeline_peak wrote:
       | 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.
        
         | jon-wood wrote:
         | Why wouldn't an open source project announce a change to the
         | place their source is hosted on their own blog? Why would they
         | want to sweep it under the rug?
        
         | ian-g wrote:
         | 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 wrote:
           | 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 wrote:
             | 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.
        
           | pipeline_peak wrote:
           | 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.
        
         | barkingcat wrote:
         | No way ... as an open source project this is the kind of thing
         | you want to tell everyone.
        
       | joemaller1 wrote:
       | Curious to see how this affects contributions.
        
       | lxe wrote:
       | > 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 wrote:
         | 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 wrote:
         | 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.
        
       | aendruk wrote:
       | 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...
        
         | a_t48 wrote:
         | `git subtree` but it might still download the whole history
        
         | gman83 wrote:
         | sparse-checkout -- https://github.blog/2020-01-17-bring-your-
         | monorepo-down-to-s...
        
       | nimbius wrote:
       | 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/
       | 
       | who made this decision?
        
         | ranman wrote:
         | FWIW not all of those outages were the core git/web product. A
         | lot of those were GitHub actions or other associated
         | functionality... but yeah it goes down disturbingly often given
         | how much we all depend on it.
        
         | stusmall wrote:
         | I don't think WebKit reasonably sees itself as a risk for US
         | sanctions unless they have an open source money laundering
         | feature that no one has told me about.
        
           | [deleted]
        
           | [deleted]
        
         | jorblumesea wrote:
         | Have you ever used SVN?
         | 
         | It's like git, but even more connected to a centralized server.
        
           | lapinot wrote:
           | I think GP is not talking about git in general, but about
           | choosing a free-tier hosting by an american commercial
           | entity, and not by the project itself or some other umbrella
           | organization.
        
         | therealmarv wrote:
         | hm, git is distributed and works offline https://git-
         | scm.com/about/distributed
        
           | profmonocle wrote:
           | It "works offline" in that you can create commits, view
           | project history, and view every branch while offline. But
           | fetching and pushing are such a common part of an engineer's
           | day-to-day workflow that a poorly-timed outage of your remote
           | repo is very disruptive, especially if you use git for
           | deployment.
        
         | [deleted]
        
         | maxwell wrote:
         | > recourselessly banning users from countries that are
         | sanctioned by the United States
         | 
         | Are you suggesting that Microsoft should intentionally opt not
         | to comply with OFAC sanctions?
         | 
         | Do you know of any non-OFAC sanctioned entities that have made
         | that choice?
         | 
         | Are you aware of any OFAC sanctioned entities that maintain
         | public accounts on any other code sharing sites?
        
           | joecool1029 wrote:
           | AFAIK Github can provide free access to public repositories
           | even if the users are subject to OFAC sanctions. In some
           | cases they've applied for (and received) exemptions to allow
           | for sales of paid services:
           | https://github.blog/2021-01-05-advancing-developer-
           | freedom-g...
        
         | klodolph wrote:
         | I think the bigger picture here is the migration to Git, since
         | that lets you keep working during an outage. SVN does not.
        
           | lapinot wrote:
           | > 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.
        
           | ajross wrote:
           | In fact the very fact that your source control hosting
           | service can be surpringly[1] unreliable is the best
           | advertisement for git you could imagine.
           | 
           | In fact, if github disappeared from the internet today, all
           | but the largest projects could just set up an ssh-accessible
           | box somewhere and continue work (code review and issue
           | interfaces notwithstanding, of course), probably with 24
           | hours.
           | 
           | [1] I work in github-cloned repositories almost full time.
           | And sure, I remember a handful of times over the past 4-5
           | years where it's been down when I wanted to push something. I
           | had no idea it was 50x/year! And that's because "working in a
           | github-cloned repository" doesn't, in fact, require much
           | contact with github itself.
        
         | schmichael wrote:
         | > github has had more than fifty outages this year alone
         | 
         | I'm a heavy user of github every day and maybe 1 or 2 of these
         | caused me any disruption whatsoever. Most of the time I think
         | they created productivity boosts as people just focused on what
         | they were working on instead of reacting to Github
         | notifications about issues or PRs or failing tests or whatever.
         | 
         | > a rocky history of recourselessly banning users from
         | countries that are sanctioned by the United States
         | 
         | This is likely a feature for companies, projects, and
         | organizations who have (or want) to adhere to the same strict
         | regulations.
        
         | [deleted]
        
       | tolmasky wrote:
       | 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
        
         | evmar wrote:
         | 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.
        
           | taberiand wrote:
           | I don't understand any developer's that aren't willing to put
           | in the time to learn how to use Git - to me, it's the single
           | greatest tool available to enable productivity and confidence
           | in changing code. There's no shame in using any one of the
           | many GUI interfaces for Git that make the process simple and
           | intuitive but even with the CLI, there are only a small
           | handful of commands that I regularly need to use to do all
           | the work of managing branches, merges, rebases and resets;
           | and a lot of the time, there's more than one way to do any
           | particular operation.
        
             | solarkraft wrote:
             | I'm totally willing to learn the magic of advanced merging,
             | but most "tell me more about Git" talks/articles rather
             | want to tell me more about its general internal structure,
             | which I find very far removed from actually using it.
             | 
             | So what's the best resource for learning more about using
             | Git?
        
               | rascul wrote:
               | https://git-scm.com/book/en/v2
        
             | saagarjha wrote:
             | > I don't understand any developer's that aren't willing to
             | put in the time to learn how to use Git
             | 
             | Other version control systems exist. Why learn Git if
             | you've already got one that works?
        
             | evmar wrote:
             | To be clear, I think many developers are comfortable enough
             | with the small handful of commands most regularly use. For
             | the more complex case of maintaining a fork of a complex
             | codebase like WebKit, it's likely you'll need a deeper
             | understanding of remotes and how to manage complex rebases,
             | especially in the presence of lots of conflicts. And
             | possibly some fancier tools like git-subtree. In particular
             | in WebKit my recollection was it was common to patch
             | something locally and eventually take it upstream, but
             | after upstream's requested modifications the patch would
             | eventually come back around and conflict with itself.
        
       | olliej wrote:
       | 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 wrote:
         | With the bugzilla issue tracker, they keep ownership.
        
         | usefulcat wrote:
         | 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.
        
         | a-dub wrote:
         | > 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)
        
         | [deleted]
        
       | mnd999 wrote:
       | Strange choice given how GitHub seems to have moved into the
       | extinguish phase.
        
         | _rrnv wrote:
         | Subversion started in that phase so maybe they're just trying
         | to delay the inevitable.
        
         | srvmshr wrote:
         | 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
        
         | olliej wrote:
         | 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 wrote:
           | https://sfconservancy.org/blog/2022/jun/30/give-up-github-
           | la...
        
           | beermonster wrote:
           | 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 wrote:
             | Yes, that was what I meant.
        
       | tibbydudeza wrote:
       | What does Apple use for source control ???. I know Google is all
       | custom and MS uses (???) a modified instance of Perforce.
        
         | saagarjha wrote:
         | Lots of Git projects. Internal development has centered around
         | using Git, even for WebKit, for several years.
        
         | bragr wrote:
         | 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 wrote:
           | 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
        
             | [deleted]
        
             | dark-star wrote:
             | long before
        
       ___________________________________________________________________
       (page generated 2022-08-31 23:00 UTC)