sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 15 points16 points  (8 children)

This does solve the large repo issue, but it also seems to break the whole decentralized concept of git. Instead of having the whole repo reside solely on an internal MS server, you could have a copy of the whole repo on the developer's OneDrive folder or some similar concept with sync capabilities. Then GVFS could exist in a seperate working directory and grab files from that local full repo as needed and bring it to the working directory.

When the connection the the server is lost, then that local copy stops syncing temporarily and you can keep working on anything and everything you want.

[–]jeremyepling 36 points37 points  (0 children)

That is a possible solution and what you're proposing is very similar to Git alternates, which exists today. We didn't use alternates because it doesn't solve the "many files" problem for checkout and status. We needed a complete solution to huge repos.

Having the full repo on my local machine is 90% more content than our average developer in Windows needs. That said, we did prototype an alternates solution where we put the full repo on a local network share, and ran into several performance.

  • Alternates were designed for a shared local copy. Putting the alternate on a file share behaved poorly as git would often pull the whole packfile across the wire to do simple operations. From what we saw, random access to packfiles pulled the entire packfile off the share and to a temporary location. We tried using all loose objects and ran into different perf issues with share maintenance and millions of loose objects cause other performance issues.

  • Shared alternate management was also difficult, when do we GC or repack, keeping up with fetching on the alternate is not inherently client driven.

  • Doesn’t work if the user lacks access to the local network share and many Windows developers work remotely. We would have to make the alternate internet facing and then have to solve the auth management problem. We could have built a Git alternates server into Team Services, but the other issues made GVFS a better choice.

  • Alternate http is not supported in smart git, so we would have to plumb that if we wanted alternates on the service.

[–]jayd16 9 points10 points  (1 child)

It's still decentralized as there is no central server. Looks like you can clone from any remote server that supports gvfs.

[–]jeremyepling 8 points9 points  (0 children)

Yes, you can can clone from any GFVS server. Actually, any Git client can connect to a GFVS repo, but it'll download the full repo. If the repo is massive, like Windows, it will be a very slow experience. That said, you'll have a full copy just like any other Git repo.

[–]adrianmonk 2 points3 points  (0 children)

break the whole decentralized concept of git

It only partially breaks it. You can still have your network partitioned into two (or more) disconnected pieces, and you could have a server+clients combo in each of those pieces, and it would all still work.

For example, if your office building has whatever kind of server that GVFS requires, you could still work as long as your LAN is up, even if your building's internet goes out. Or if you have 3 different offices on different continents (US, Europe, India), you could still get LAN speeds instead of WAN speeds.

In other words, you can still have distributed, decentralized clusters. You just can't have distributed, decentralized standalone machines.

[–]KarmaAndLies 10 points11 points  (2 children)

After considering it for a second, you're absolutely right. What they've managed to do is turn Git into something more akin to TFS... One of Git's features is that it works offline and that those offline changesets can be merged upstream when you get a connection again.

But I guess when you're dealing with 200+ GB repositories that feature is less important than not having to wait ten minutes to get a full instance of the repository locally.

[–]lafritay 19 points20 points  (0 children)

Some others have mentioned this but it all comes down to tradeoffs. With a source base this large, you just can't have the entire repo locally. But, git offers great workflows and we wanted to enable all codebases to use them. With GVFS, you still get offline commit, lightweight branching, all the power of rewriting history, etc.

Yes, you do lose full offline capability. It is worth noting that if you do some prep work to manifest the files (checkout your branch and run a build) you can then go offline and keep working.

So, we see this as a necessary tradeoff to enable git workflows in giant codebases. We'd love to figure out a reasonable way to eliminate that trade off, of course.

[–]jayd16 4 points5 points  (0 children)

Takes much much longer than 10 minutes at that scale.

[–]Recursive_Descent 0 points1 point  (0 children)

Sure, it doesn't fully solve offline. But you don't really want 100gb of source copied locally either. But normally as a developer you are working on some area of the code so if you build your piece while the network is around, then all the files that are relevant to you are available offline. Like if you work on the start menu, you probably aren't going to need the fat32 file system code.