HackerTrans
TopNewTrendsCommentsPastAskShowJobs

ethomson

no profile record

Submissions

The largest Git repo

blogs.msdn.microsoft.com
1,053 points·by ethomson·hace 9 años·402 comments

comments

ethomson
·hace 3 meses·discuss
Saddened to hear this. As a former GitHub employee, Mona was _a thing_. She had a backstory, and obviously a lot of designs. Simon’s initial work had a lot of impact on GitHub’s design and communications philosophy.

Coincidentally, when I moved to the UK, I had arranged for a taxi from the airport that never showed up. But Simon’s did, apparently. I sat there at a coffeeshop and stared at a taxi driver with a sign for Simon Oxley for a jetlagged hour or so while I waited for mine. I had hoped to catch him for a chat but apparently missed the connection.

More recently, we chatted about one of his designs that I adored and I had asked him about using it for an open source project that I had in mind. He graciously offered me to use it for noncommercial purposes. I got busy with, well, life, and didn’t pursue that. I’m feeling now like I should dust it off and see if it’s useful.

Godspeed, Simon.
ethomson
·hace 9 años·discuss
300 GB is not the size of _the repository_. It's the size of the code base - the checked out tree of source, tests, build tools, etc - without history.

It's certainly possible that somebody created a 1 TB source tree in Git, but what we've never heard of is somebody actually _using_ such a source tree, with 4000 or more developers, for their daily work in producing a product.

I say this with some certainty because if somebody had succeeded, they would have needed to make similar changes to Git to be successful, though of course they could have kept such changes secret.
ethomson
·hace 9 años·discuss
CVS and SVN are probably a bit better at scaling than (stock) Git. Perforce and TFVC _are certainly_ better at scaling than (again, stock, out-of-the-box) Git. That was their entire goal: handle very large source trees (Windows-sized source trees) effectively. That's why they have checkout/edit/checkin semantics, which is also one of the reasons that everybody hates using them.

GVFS intends to add the ability to scale to Git, through patches to Git itself and a custom driver. I don't think this is a hack - by no means is it the first version control system to introduce a filesystem level component. Git with GVFS works wonderfully while offline for any file that you already have fetched from the server.

If this sounds like a limitation, then remember that these systems like Perforce and TFVC _also_ have limitations when you're offline: you can continue to edit any file that you've checked out but you can't check out new files.

You can of course _force_ the issue with a checkout/edit/checkin but then you'll need to run some command to reconcile your changes once you return online. This seems increasingly less important as internet becomes ever more prevalent. I had wifi on my most recent trans-Atlantic flight.

I'm not sure what determines when something is "a hack" or not, but I'd certainly rather use Git with GVFS than a heavyweight centralized version control system if I could. Your mileage, as always, may vary.
ethomson
·hace 9 años·discuss
Microsoft's tooling is Windows only _today_. GVFS is open source _and_ we are actively hiring filesystem hackers for Linux/macOS.