Slashdot Mirror
Microsoft Introduces GVFS (Git Virtual File System) (microsoft.com)
Saeed Noursalehi, principal program manager at Microsoft, writes on a blog post: We've been working hard on a solution that allows the Git client to scale to repos of any size. Today, we're introducing GVFS (Git Virtual File System), which virtualizes the file system beneath your repo and makes it appear as though all the files in your repo are present, but in reality only downloads a file the first time it is opened. GVFS also actively manages how much of the repo Git has to consider in operations like checkout and status, since any file that has not been hydrated can be safely ignored. And because we do this all at the file system level, your IDEs and build tools don't need to change at all! In a repo that is this large, no developer builds the entire source tree. Instead, they typically download the build outputs from the most recent official build, and only build a small portion of the sources related to the area they are modifying. Therefore, even though there are over 3 million files in the repo, a typical developer will only need to download and use about 50-100K of those files. With GVFS, this means that they now have a Git experience that is much more manageable: clone now takes a few minutes instead of 12+ hours, checkout takes 30 seconds instead of 2-3 hours, and status takes 4-5 seconds instead of 10 minutes. And we're working on making those numbers even better.
Would be a dream come true. Ditch the abomination (Windows) and do like Jobs did by putting a nice GUI on top of a "Unix".
There aren't THAT many repos with over 3 million files in them.
The great majority of projects I've been on have been around the 100k-300k range and doing a build (to properly test the product) required ALL of them.
And even then, once you've got all of them the first time, GIT does the diffing automatically so it "scales" already.
Maybe MS could put some of their vast R&D efforts to to something more useful... like having their free Visual Studio Code editor handle files bigger than 1gb?
The whole point of git is that you have identical copy on your machine. Why take away git's biggest advantage?
Avantgarde Hebrew science fiction
so its just a simulated version of git that requires constant internet access ... next
While a vfs sounds like a great idea, I think in theory it's only of use for very, very large repos. Even then I wonder if the exact same issues that made Clearcase suck would make it suck even with Git.
Now when I have a gvfs error, I won't know if it's gnome or git!
"Hey, how can we do what GitHub does, only stupider?"
Mr. Hu is not a ninja.
git is not a company. That company had nothing to do with git apart from the fact that they used git like many other companies.
That is really fucking cool! This is going to revolutionize how software development is done. Imagine being able to use git like an efficient file system without the overhead of downloading everything all the time. I am willing to bet that within a year or two the majority of git projects will be built this way, even further eroding Linux's popularity with developers. I am already seeing most of my colleagues join me in dumping Linux and switching over to Windows 10 with the Linux subsystem so it is pretty much inevitable. THIS, this is what real innovation looks like.
So they can do this - have something that looks a lot like Placeholders did in OneDrive for Windows 8, but apparently that feature was "too confusing" for their users and it had to be removed. Great. Nice to see that Placeholders did finally make a comeback - but only for developers using Git. Way to go you stupid 'Git... Bring Placeholders back to OneDrive!
Just curious what the author of GIT has to say about this. He can point out the truth with absolute authority.
(Reinvented a square wheel? Solved a non-problem? Cured a symptom?)
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
If your developers aren't using all the files then you should probably split your repository.
While I can see the value of making versioning control system manipulation seamless from filesystem level manipulation, the issue of space isn't really one that crops up in any significant fashion. What I want is to be able to manipulate different versions side-by-side.
Does anyone else here notice that this is a solution created by Microsoft, for a problem created by Microsoft?
Only (or almost only) Microsoft would abuse a repo in such a way that it had 3 million files, but instead of refactoring things correctly, they would rather break distributed source control, and implement an entire file system.
Thank you for adding a band-aid of a solution to a problem I never had.
#Nailedit
Too bad there's already a gvfs, which is used to interface with mobile devices that use MTP to move files.
Excellent that they took their time to made sure there was not any name clash with something else in the filesystem realm
Wenn ist das Nunstueck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput.
I get an error message that says the error message needs replacing with a custom one.
What a brilliant idea.
Because I never found git processing times to be a problem.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I love the Internet.
The whole point of git is that you have identical copy on your machine. Why take away git's biggest advantage?
Because it's biggest advantage is also one of it's greatest inefficiencies and frankly on a large project chances are you may not need it all. The whole point is you have an identical copy on your machine of what you're working on
So buy a bigger disk. They're cheap.
Why did they do it? It's obvious: it's the bait on the hook to get you to break git and your open source projects (even CURRENT ones) that compete with them.
By keeping you from having a full copy of the repository, they break git: If there are files that you didn't use in recent checkouts, they're not stored locally or not brought up to date when you pull. If something goes wrong externally - like loss or corruption at a cloud site (such as the recent lost-update debacle) you have no non-microsoft-git-internals-expert way to recover - maybe no way to recover at all.
You lose the ability to work offline. You lose the ability to look at history, or parts of the repository you haven't been to yet, without being back on line to a working and trustworthy external server, and so on.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Wait a second.
MS just invented an efficient way to checkout the Linux kernel on windows, so you can get the kernel sources, compile it, and then run Linux and ditch Windows ?
That's great !!
aaaaaaa
https://en.wikipedia.org/wiki/GVfs
Is MS doing that on purpose or did really nobody think to google the name beforehand?
git is not a company.
I respectfully differ - Microsoft is, of course, git. The gittest, actually.
Perhaps they could choose another abbreviations, as GVfs has for a long time been used for the Gnome Virtual Filesystem
What repo are they using where clone takes a few hours and checkout takes a few minutes? Holy shit!!! What do they have like 500 gig files in their repo?
So buy a bigger disk. They're cheap.
That's not the problem. It's the time to process all those files every time you run commands like checkout status diff etc.
Are YOU really having speed issues now?
If not, don't expect to as your project grows, either. As long as the Moore's law variants apply and you don't add developers at an exponential rate, the machines will improve exponentially, wihch is faster than the repository grows. (Even if you DO add developers exponentially the output per developers drops off quickly.)
If you ARE having trouble I'd bet you didn't partition your repositories at project, application/subsystem, or API boundaries Git works fine if you have, say, one repository for the compiler support / standard library or vendor's SDK, another for your project's application, maybe a third for your-stuff specific libraries shared among multiple projects. You glue them together in the makefile common inclusions.
If you aren't crossing a repository boundary where you have separate components that have to interact across distinct release versions, you did something wrong. Even diverge-converge approaches won't give you a good way to test across those version combinations or protect you from change-storms unrelated to YOUR project - not just with git, but with any SCCS I'm familiar with. (And I've been programming - and/or designing digital hardware - for a living since computers were just switching from using tubes.)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Embrace, EXTEND.......(then what?)
If you just cleaned the small percentage that was dirty enough to require cleaning, you accomplished what was needed in one minute instead of a few hours. Why dust off the boxes up in the attic every time you wipe down the kitchen counter?
MS just invented an efficient way to checkout the Linux kernel on windows
Unless you go into the Windows registry to make the underlying file system case sensitive, that probably won't work. The Linux kernel sources sometimes have files in the same directory that only differ by case, like
net/netfilter/xt_hl.c
net/netfilter/xt_HL.c
includes/uapi/linux/netfilter_ipv4/ipt_ecn.h
includes/uapi/linux/netfilter_ipv4/ipt_ECN.h
It's not just a problem for the kernel, by the way. Having both "Makefile" and "makefile" in the same directory isn't unheard of. GNU make will then default to the latter. And it breaks under standard Windows.
Wait a second.
MS just invented an efficient way to checkout the Linux kernel on windows, so you can get the kernel sources, compile it, and then run Linux and ditch Windows ?
That's great !!
Seeing as how the only purpose of IE/Edge is to download Chrome/Firefox, I guess they figured that was the next logical step...
This worked just fine with Ubuntu for Windows 10 app.
This worked just fine with Ubuntu for Windows 10 app.
No, it doesn't. Ubuntu under Windows 10 runs on WSL kernel emulation, not the linux kernel proper.
and BOOOM! They can swap malicious files against your files and sneak them into your system from their cloud. FUN!
Lately they stole the name Neon from the KDE distribution, now they steal the name GVFS from GNOME. Who's next? Stealing something from the cinnamon desktop? Or maybe Some eXtended Filemanager for windows CE (XFCE)?
Wait a second.
MS just invented an efficient way to checkout the Linux kernel on windows, so you can get the kernel sources, compile it, and then run Linux and ditch Windows ?
That's great !!
And they use Android on Visual Studio and develop Ximarron with an Apache style license for Linux, Android, and MacOSX development ... on VS 2015 community edition and VS 2015 also uses GIT too.
Yes, MS is getting with the times since Windows is not what it once was. Amazing isn't it when competition is allowed again.
http://saveie6.com/
This sounds an awful lot like the days when Clearcase served up a database over NFS to an SMB server as a file system "view" of a repository .
Nothing evolves faster than the word of god in the minds of men who think themselves divinely inspired.
About time somebody did this, great work Microsoft team.
>>net/netfilter/xt_hl.c
>>net/netfilter/xt_HL.c
>>includes/uapi/linux/netfilter_ipv4/ipt_ecn.h
>>includes/uapi/linux/netfilter_ipv4/ipt_ECN.h
That's really bad naming practice.
I'm not familiar with the linux source, but wow.... This would never pass a review in my small team...
aaaaaaa
You failed to answer the question. Because you know he's right.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
Doesn't that defeat the purpose of git? Now it's no longer fully decentralized and offline. Sounds like Subversion would be a better solution to the problem.
That's really bad naming practice.
It's consistent naming for that project. ... Windows.
Any kernel configuration for netfilter with match support gets lower case names, and with target support it gets upper case names. In some cases there is support for both.
And the only real problem with this is
But what's being unsaid throughout this is whether this works with a standard Git server, or whether it only works with a special Microsoft-kluged server. While the former is vaguely interesting, the latter merits only a derisive snort.
Editor, A1-AAA AmeriCaptions
It's not an emulator though...
The post was ridiculous. It is so easy to counter it isn't funny. The clone is not complete because the counters are still dirty (but we'll clean them later. The next time you look at them you'll have to wait until we clean them to see them)
Nah. Linux is a hacked together kernel with hardly a design thought anywhere to be found. It would be better to use BSD, because it's much more stable, faster and was designed by computer experts and not some Finnish kid.
GVFS feels like a philosophical disconnect with GIT and a software tool created to work around a lack of software architecture. It probably would be a better idea to fix the software architecture problem.
Polytron's tool chain supported partial local builds back in the 80's. We used Polymake and PVCS to build Comshare's EIS. If you changed just one C file, that was all that compiled on your system. Polymake basically had two paths it looked at for all dependencies and their lib command had a nice replace-module command. Fixing the architecture and having a better make seems like a better solution than monkeying with the source code control system.
If MS released the GVFS under an Open Source License, then MAYBE their recent posturing re Open Source and Linux has some sincerity to it.
If they did not then it is probably more Embrace, Extend, Extinguish.
softcodeer
wow....solving a problem in GIT in a way that doesn't improve GIT in any way... go new MS...
[Submitting a separate pull request from each branch of your fork to the upstream project] can be done entirely from the Web UI as long as you're only making small changes that touch one file at a time
I was asked to make three pull requests to HTTPS Everywhere, each to make one small change to a different section of the same FAQ. Because one of the changes would reorder and then combine two sections, I fear an error message that my pull request "has conflicts that must be resolved". GitHub's page about merge conflicts states that for many "merge conflicts, you must resolve the merge conflict locally on the command line."
It may be consistent, but it is terrible.
Better would be:
xt_match_hl.c
xt_target_HL.c
Just because you can, doesn't mean you should.
It may be consistent, but it is terrible.
[...]
Just because you can, doesn't mean you should.
If you grew up with and are used to case sensitive file systems, and aren't aware of limitations in other systems because they've never been part of your work and life, why is this terrible?
The practice of Makefile + makefile is far from uncommon. With Makefile being the "production" one, and makefile having local modifications.
If I remember correctly, one language used to have file names like Net::NIS and CRC::CCITT too, until porting was startted, and someone discovered that this would break in some other OSes.
And I'm sure that one or more projects have had a subdirectory named con - which works fine, except in Windows, where con is a reserved word.
And back in the 80s/90s, it was not uncommon to have both pack and compress on a system, with both .z and .Z extensions. One system I used had its compressed man pages as both .z and .Z, in the same directories. Where .z was used for local pages due to the unpack speed, and .Z was used for NFS mounted pages, due to higher compression. Was that terrible?
Unless you plan to port something to another OS or are familiar with it, I don't think it's terrible at all if you don't make adjustments for it.
Or to put it another way, I don't see a lot of Windows users take care to always be consistent with case, so things won't break on case sensitive systems. And I'm fine with that as long as they intend to keep their work in Windows.
I don't understand how the that EULA goes along with the MIT license. How are they compatible? Am I missing something?
This is a hideously bad idea. Every time someone clones a repo, they effectively have a made a full backup of the source. As we just saw with GitLab, one cannot ever have too many backups.
Yeah.
it would be better to use BSD or Hurd.
But let's face it, the world uses Linux.
And it's not developped by a finnish kid any more :
https://lwn.net/Articles/65463...
(None) 3.9%
(Unknown) 3.5%
The remaining 92,6% is big corps.
aaaaaaa