7 ms·

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 wo

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.
- taberiand 4y ago
  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.
  - evmar 4y ago
    To be clear, I think many developers are comfortable enough with the small handful of commands most regularly use. For the more advanced case of maintaining a fork of a high-velocity 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.
  - solarkraft 4y ago
    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 4y ago
      https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2
    - LegionMammal978 4y ago
      Personally, I found https://learngitbranching.js.org/ https://learngitbranching.js.org/ surprisingly helpful for getting a mental model of Git usage, even though I had already been using Git for a couple years. As always with learning resources, YMMV.
emmelaich 4y ago
You can usually rsync the whole lot at first then and checkout from the copy. Then fiddle with the SVK config to set upstream to the real origin. OR have admins do a local checkout on the server for people to rsync, then do other appropriate config fiddles.
- danudey 4y ago
  If you have that access, you should use svnsync instead. For a large repository, running rsync can take hours just hashing all the individual files on either end to compare, just to eventually update one or two revisions. svnsync is much more 'aware', and so it's much easier to keep up to date if necessary.
  - emmelaich 4y ago
    True. Or just zip/tar it up and then rsync that. To be clear I was talking about a one time thing, not continued updates -- which would be done with SVK
lnxg33k1 4y ago
It’s not funny at all if you lived with these kind of bullshits
ridiculous_fish 4y ago
Fun story indeed! I worked in the Cocoa group when we migrated from cvs to git. But it wasn't exactly cvs, it was ocvs, which was an ancient forked version of cvs that handled certain directories (nibs) as tar files. There was no direct importer from cvs to git, so we had to go through Subversion as an intermediate. This was Cocoa so its history was very long, but the earliest history turned out to be mangled, so some poor fellow was tasked with learning how to repair CVS history, only so it could be migrated to git. Once we got to git our lives were so much better. I'm glad we skipped svn. ocvs man page for any masochists reading this: https://opensource.apple.com/source/cvs_wrapped/cvs_wrapped-5.1/cvs_wrapped/man/ocvs.1.auto.html https://opensource.apple.com/source/cvs_wrapped/cvs_wrapped-...
- mrpippy 4y ago
  Did that cvs history date back to NeXT? Or was there some initial Rhapsody import?
- justinator 4y ago
  I'm curious why it wouldn't make sense to just think, "Before THIS DATE we just don't care about history anymore". I look at my main project and I'm fairly happy to forget about 90% of the branches I have hanging around and half the lifetime of coding it, and it's just 100k LOC. (except I haven't. Why haven't I?)
  - saagarjha 4y ago
    It’s generally useful to have history around when you’re digging through a codebase for bugs or curiosity.
    - justinator 4y ago
      But where do you draw the line when migrating to a superior source control system isn't possible because of your current source control system? If curiosity is what you're wanting to allow, keep the current source control system on ice, and move everything to the superior one at its current state + a few releases back. Save a decade or two. It seems to me a version (sic!) of technical debt otherwise.
LordDragonfang 4y ago
As a (relatively) young dev, I always find it wild whenever I'm reminded that git is such a young tool, because it feels like it should be contemporaries with vim, perl, or even emacs with how fundamental it is to modern software development. Hell, I remember when python was the fancy new kid on the block, and even python2 is a full five years older than git.
- scambier 4y ago
  I started working in 2012, and my colleagues used usb keys to pass projects around. I was a bit... surprised.
- frou_dh 4y ago
  The thing that continues to feel strange to me is that Python is actually older than Linux.
lostgame 4y ago
That someone who worked on the iPhone Team responded here - much less with such a detailed reply - is the reason Hacker News is one of my internet GOATs. Thank you - first for your contribution to the product; and secondly, thank you for opening up a window into the glass wall that is Apple.

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.

taberiand 4y ago
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.
- evmar 4y ago
  To be clear, I think many developers are comfortable enough with the small handful of commands most regularly use. For the more advanced case of maintaining a fork of a high-velocity 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.
- solarkraft 4y ago
  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 4y ago
    https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2
  - LegionMammal978 4y ago
    Personally, I found https://learngitbranching.js.org/ https://learngitbranching.js.org/ surprisingly helpful for getting a mental model of Git usage, even though I had already been using Git for a couple years. As always with learning resources, YMMV.

emmelaich 4y ago

You can usually rsync the whole lot at first then and checkout from the copy. Then fiddle with the SVK config to set upstream to the real origin. OR have admins do a local checkout on the server for people to rsync, then do other appropriate config fiddles.

danudey 4y ago
If you have that access, you should use svnsync instead. For a large repository, running rsync can take hours just hashing all the individual files on either end to compare, just to eventually update one or two revisions. svnsync is much more 'aware', and so it's much easier to keep up to date if necessary.
- emmelaich 4y ago
  True. Or just zip/tar it up and then rsync that. To be clear I was talking about a one time thing, not continued updates -- which would be done with SVK

lnxg33k1 4y ago

It’s not funny at all if you lived with these kind of bullshits

ridiculous_fish 4y ago

Fun story indeed! I worked in the Cocoa group when we migrated from cvs to git. But it wasn't exactly cvs, it was ocvs, which was an ancient forked version of cvs that handled certain directories (nibs) as tar files. There was no direct importer from cvs to git, so we had to go through Subversion as an intermediate. This was Cocoa so its history was very long, but the earliest history turned out to be mangled, so some poor fellow was tasked with learning how to repair CVS history, only so it could be migrated to git. Once we got to git our lives were so much better. I'm glad we skipped svn. ocvs man page for any masochists reading this: https://opensource.apple.com/source/cvs_wrapped/cvs_wrapped-5.1/cvs_wrapped/man/ocvs.1.auto.html https://opensource.apple.com/source/cvs_wrapped/cvs_wrapped-...

mrpippy 4y ago
Did that cvs history date back to NeXT? Or was there some initial Rhapsody import?
justinator 4y ago
I'm curious why it wouldn't make sense to just think, "Before THIS DATE we just don't care about history anymore". I look at my main project and I'm fairly happy to forget about 90% of the branches I have hanging around and half the lifetime of coding it, and it's just 100k LOC. (except I haven't. Why haven't I?)
- saagarjha 4y ago
  It’s generally useful to have history around when you’re digging through a codebase for bugs or curiosity.
  - justinator 4y ago
    But where do you draw the line when migrating to a superior source control system isn't possible because of your current source control system? If curiosity is what you're wanting to allow, keep the current source control system on ice, and move everything to the superior one at its current state + a few releases back. Save a decade or two. It seems to me a version (sic!) of technical debt otherwise.

LordDragonfang 4y ago

As a (relatively) young dev, I always find it wild whenever I'm reminded that git is such a young tool, because it feels like it should be contemporaries with vim, perl, or even emacs with how fundamental it is to modern software development. Hell, I remember when python was the fancy new kid on the block, and even python2 is a full five years older than git.

scambier 4y ago
I started working in 2012, and my colleagues used usb keys to pass projects around. I was a bit... surprised.
frou_dh 4y ago
The thing that continues to feel strange to me is that Python is actually older than Linux.

lostgame 4y ago

That someone who worked on the iPhone Team responded here - much less with such a detailed reply - is the reason Hacker News is one of my internet GOATs. Thank you - first for your contribution to the product; and secondly, thank you for opening up a window into the glass wall that is Apple.