So, if windows engineers are using git now, who is using TFVC? That's Team Foundation Version Control- the original TFS version control engine.
The largest Git repo
191–200 of 416 posts
Re: The largest Git repo
#192Linus must be very proud - his favourite software Windows - now depends on GIT.
I hope this largest repository has enough space for Clippy as Linus loves it.
Re: The largest Git repo
#193Earlier quoted context omitted.
Google also uses a single giant repo...
Why is that a "good reason" to do it?
I think this is like the "your data isn't big enough for HDFS" argument earlier this week. The point I take away is that at some stage of your growth, this will be a logical decision. I don't think it implies that the same model works for your organization.
Re: The largest Git repo
#194At Sun Microsystems, Inc., (RIP) we have many "gates" (repos) that made up Solaris. Cross-gate development was somewhat more involved, but still not bad. Basically: you installed the latest build of all of Solaris, then updated the bits from your clones of the gates in question. Still, a single repo is great if it can scale, and GVFS sounds great!
But that's not what I came in to say.
I came in to describe the rebase (not merge!) workflow we used at Sun, which I recommend to anyone running a project the size of Solaris (or larger, in the case of Windows), or, really, even to much smaller projects.
For single-developer projects, you just rebased onto the latest upstream periodically (and finally just before pushing).
For larger projects, the project would run their own upstream that developers would use. The project would periodically rebase onto the latest upstream. Developers would periodically rebase onto their upstream: the project's repo.
The result was clean, linear history in the master repository. By and large one never cared about intra-project history, though project repos were archived anyways so that where one needed to dig through project-internal history ("did they try a different alternative and found it didn't work well?"), one could.
I strongly recommend rebase workflows over merge workflows. In particular, I recommend it to Microsoft.
Re: The largest Git repo
#195Coming from the days of CVS and SVN, git was a freaking miracle in terms of performance, so I have to just put things into perspective here when the topmost issue of git is performance . It's just a testament how huge are the codebases we're dealing with (Windows over there, but also Android, and surely countless others), the staggering amount of code we're wrangling around these days and the level of collaboration i…
Broadly speaking this is true, but note that in some ways CVS and SVN are better at scaling than Git. - They support checking out a subdirectory without downloading the rest of the repo, as well as omitting directories in a checkout. Indeed, in SVN, branches are just subdirectories, so almost all checkouts are of subdirectories. You can't really do this in Git; you can do sparse checkouts (i.e. omitting things when c…
GVFS won't fix this because you still need to lock opaque binary files, which is something Perforce supports.
Re: The largest Git repo
#196I have tremendous respect for Microsoft pulling itself together over the past few years.
This may be the thing that gets Google to switch. They like having every piece of code in a single repository which Git cannot handle. Now that it is somewhat proven, maybe Google will leverage GVFS on Windows and create a FUSE solution for Linux.
Google used to have a Perforce frankenstein, but now they have their own VCS.
Re: The largest Git repo
#197I have tremendous respect for Microsoft pulling itself together over the past few years.
This may be the thing that gets Google to switch. They like having every piece of code in a single repository which Git cannot handle. Now that it is somewhat proven, maybe Google will leverage GVFS on Windows and create a FUSE solution for Linux.
I'd rather see google open up their monorepo as a platform, and compete with github. git is fine, but there's something compelling about a monorepo. Whether they do it one-monorepo-per-account, or one-global-monorepo, or some mix of the two, would be interesting to see how it shapes up.
Re: The largest Git repo
#198Earlier quoted context omitted.
This may be the thing that gets Google to switch. They like having every piece of code in a single repository which Git cannot handle. Now that it is somewhat proven, maybe Google will leverage GVFS on Windows and create a FUSE solution for Linux.
I'd rather see google open up their monorepo as a platform, and compete with github. git is fine, but there's something compelling about a monorepo. Whether they do it one-monorepo-per-account, or one-global-monorepo, or some mix of the two, would be interesting to see how it shapes up.
"one-global-monorepo" caused me to envision a beautiful/horrifying Borg-like future where all code in the universe was in a single place and worked together.
Re: The largest Git repo
#199Linus must be very proud - his favourite software Windows - now depends on GIT.
I am very certain that Linus would read this article and curse the jaw dropping stupidity of the whole endeavor. They've basically taken a tool he wrote to do real distributed source control that can scale and turned it into a central server.
Git was never meant to be used this way and I know he'd be horrified+amused in the extreme.
Re: The largest Git repo
#200Earlier quoted context omitted.
Wouldn't IPFS be much, much more suitable for this purpose?
IIRC, there are permanence and equitable sharing guarantee concerns with IPFS. The former at least can be helped by pinning I think.
Ah, I see, yes. It would be probabilistic, unless there was some way to coordinate sharing (eg downloading the least shared file first).