Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing GVFS: Git Virtual File System

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

41–50 of 287 posts

Re: Announcing GVFS: Git Virtual File System

#41

Post by testUser69 »

anon987 wrote: post #34
kentt wrote: post #22

It's disappointing that all the comments are so negative. This is a great idea and solves a real problem for a lot of use cases. I remembering years ago Facebook says it had this problem. A lot of the comments were centered around that you could change your codebase to for what git can do. I'm glad there's another option now.

It's because the 'problem' it solves is a corner case that's rarely encountered. I love their absurd examples of repos that take 12 hours to download. How many people have that problem, really? All they did is create a caching layer.

Shhhhh! It's Microsoft, we're not allowed to have a negative opinion of anything they do on hacker news.

Re: Announcing GVFS: Git Virtual File System

#42

Post by gvb »

Using git with large repos and large (binary blob) files has been a pain point for quite a while. There have been several attempts to solve the problem, none of which have really taken off. I think all the attempts have been (too) proprietary – without wide support, it doesn’t get adopted.

I'll be watching this to see if Microsoft can break the logjam. By open sourcing the client and protocol, there is potential...

Other attempts:

* https://github.com/blog/1986-announcing-git-large-file-stora...

* https://confluence.atlassian.com/bitbucketserver/git-large-f...

Article on GitHub’s implementation and issues (2015): https://medium.com/@megastep/github-s-large-file-storage-is-...

Re: Announcing GVFS: Git Virtual File System

#44

Post by grovegames »

sametmax wrote: post #13
dewyatt wrote: post #5

I think they could have picked a name that doesn't conflict with GNOME Virtual File System (GVfs).

That's what my first thought. "dick move". But they probably didn't know about it.

I've built a personalized linux from the kernel up a couple times, and it never even popped into my head. Lets be fair to Microsoft, the nix world is vast, and not exactly easy to navigate if you don't live there. I live in all three worlds, and there are only so many letters. It drives me nuts when I just want a code name for a project, because I can no longer find unique words that aren't used by some project somewhere.

I mean, git itself did this in the beginning.

Microsoft, under Nadella has made me not hate Microsoft again, and that's a tall order because I'm over 40. This is an impressive move, and if they effectively execute all the bits that are possible here, this is just some great work.

(Oh, and I can't even use the word nix now as a catch all for all the POSIX/ POSIX(like) OSs because of nixOS.)

I think going forward, we just have to accept name collision.

Re: Announcing GVFS: Git Virtual File System

#45

Post by FLGMwt »

wslh wrote: post #20
dewyatt wrote: post #5

I think they could have picked a name that doesn't conflict with GNOME Virtual File System (GVfs).

They used to choose very bad names like .NET or COM [1] (this predates Internet) makes searching information very tricky. MSDN doesn't help. [1] https://en.wikipedia.org/wiki/Component_Object_Model

.NET is still rough naming-wise. We're porting a project to .NET Core Runtime which requires porting over to EF Core and ASP.NET Core (neither of which require being on Core Runtime).

Our internal libraries need to be compatible with the Core Runtime, so we have to have them target .NET Standard, which is compatible w/ the full .NET Framework or .NET Core. To target .NET Standard, you need the .NET Core SDK/CLI which includes the `dotnet` tool, which is almost never clarified as "the SDK/CLI" in documentation or in talks, but usually just ".NET Core".

Another minor annoyance: to build a .NET Standard-compatible library, you reference the "NETStandardLibrary" NuGet package. Makes a fair amount of sense, but is hard to talk about.

If you're running on Windows and want a smaller server footprint, you can use Windows Server Nano, which requires your apps to target .NET Core Runtime (not .NET Full Framework). Note that this requirement is not true for Windows Server Core. -_-

Re: Announcing GVFS: Git Virtual File System

#47

Post by jbergens »

mox1 wrote: post #35
kentt wrote: post #22

It's disappointing that all the comments are so negative. This is a great idea and solves a real problem for a lot of use cases. I remembering years ago Facebook says it had this problem. A lot of the comments were centered around that you could change your codebase to for what git can do. I'm glad there's another option now.

Yes they did. They choose to scale out Mecurial to solve their problem. Wonder if they still use Mercurial? https://code.facebook.com/posts/218678814984400/scaling-merc...

They did a couple of months ago so I assume they still do.

Re: Announcing GVFS: Git Virtual File System

#48

Post by SippinLean »

testUser69 wrote: post #41
anon987 wrote: post #34

Earlier quoted context omitted.

It's because the 'problem' it solves is a corner case that's rarely encountered. I love their absurd examples of repos that take 12 hours to download. How many people have that problem, really? All they did is create a caching layer.

Shhhhh! It's Microsoft, we're not allowed to have a negative opinion of anything they do on hacker news.

The recent Windows 10 thread was full of criticism for MS

Re: Announcing GVFS: Git Virtual File System

#49

Post by kyrra »

mox1 wrote: post #35
kentt wrote: post #22

It's disappointing that all the comments are so negative. This is a great idea and solves a real problem for a lot of use cases. I remembering years ago Facebook says it had this problem. A lot of the comments were centered around that you could change your codebase to for what git can do. I'm glad there's another option now.

Yes they did. They choose to scale out Mecurial to solve their problem. Wonder if they still use Mercurial? https://code.facebook.com/posts/218678814984400/scaling-merc...

Both Facebook and Google are continuing to contribute to Mercurial, so they both have some vested interest in it. If you poke around the commits on the repo[0] you'll see commits from people with @fb.com and @google.com email addresses. The mailing lists also has activity from both companies still.

As well, the Mercurial team does quarterly sprints (I believe), and Google is hosting the next one[1].

[0] https://www.mercurial-scm.org/repo/hg

[1] https://www.mercurial-scm.org/wiki/4.2sprint

Re: Announcing GVFS: Git Virtual File System

#50

Post by wyldfire »

I'm immediately reminded of MVFS and clearcase. Lots of companies still use clearcase, but IMO it's not the best tool for the job. git is superior in most dimensions. From what this article says, it's not quite the same as clearcase but there's certainly some hints of similarities.

The biggest PITA with clearcase was keeping their lousy MVFS kernel module in sync with ever-advancing linux distros.

I really liked Clearcase in 1999, it was an incredible advancement over other offerings then. MVFS was like "yeah! this is how I'd design a sweet revision control system. Transparent revision access according to a ranked set of rules, read-only files until checked out." But with global collaborators, multi-site was too complex IMO. And overall, clearcase was so different from other revision control systems that training people on it was a headache. Performance for dynamic views would suffer for elements whose vtrees took a lot of branches. Derived objects no longer made sense -- just too slow. Local disk was cheap now, it got bigger much faster than object files.

> However, we also have a handful of teams with repos of unusual size! ... You can see that in action when you run “git checkout” and it takes up to 3 hours, or even a simple “git status” takes almost 10 minutes to run. That’s assuming you can get past the “git clone”, which takes 12+ hours.

This seems like a way-out-there use case, but it's good to know that there's other solutions. I'd be tempted to partition the codebase by decades or something.

Post reply on HN