
More on GVFS - dstaheli
https://blogs.msdn.microsoft.com/bharry/2017/02/07/more-on-gvfs/
======
qarioz
GVFS stands for GNOME Virtual file system since 2007. Looking at you
Microsoft.

~~~
sho_hn
Not sure why you're being downvoted. That's indeed what gvfs commonly stands
for in industry. It's a poor and confusing name choice.

~~~
woof
Outside the "industry" (aka the small world of GNOME and KDE), GVFS is not
commonly known at all.

For the Gnome community this might be both poor and confusing, for the rest of
us it's ... meh.

~~~
scbrg
That's a fairly good argument to ignore any name collision; "oh, it only
affects people that are not me".

Given that the products are quite similar - both are _virtual file systems_
after all - confusion is actually quite likely. If you're the kind of person
who has reasons to speak about virtual filesystems at all (which, honestly,
most people don't) you should probably know about both.

Had this been back in the day one would guess it was deliberate... but hey,
everybody tells me Microsoft are supposed to be good guys these days, so I
guess Hanlon's Razor applies.

~~~
AnkhMorporkian
I see no problem in it in that the two domains are very, very unlikely to be
confused in context. Pretty much the only time confusion is likely to be sown
is if there is a headlines akin to the one submitted here.

AFAICT, there's essentially no overlap of features beyond the fact that
they're virtual file systems. The feature sets are completely different, and
there's no intersection where if you read more than a few words into whatever
you're looking at you'll be left scratching your head thinking "Oh jeez, which
one is it this time?"

------
ekidd
From the article:

> _Lots of branches – Users of Git create branches pretty prolifically. It’s
> not uncommon for an engineer to build up ~20 branches over time and multiply
> 20 by, say 5000 engineers and that’s 100,000 branches. Git just won’t be
> usable. To solve this, we built a feature we call “limited refs” into our
> Git service (Team Services and TFS) that will cause the service to pretend
> that only the branches “you care about” are projected to your Git client.
> You can favorite the branches you want and Git will be happy._

This is almost certainly a result of trying to have one company-wide
monolithic repository that holds the source code of hundreds or thousands of
separate projects.

Git is more pleasant when you break your codebase into isolated components.
These can be pretty large—the Linux kernel has 16 million lines of code—but if
your codebase is many times larger than a complete modern kernel, you might
want to split it.

If you have 5,000 engineers all pushing branches to a single master git
repository, you may want to either rethink your repository structure, or at
least have maintainer subtrees the way Linux does.

~~~
izacus
> Git is more pleasant when you break your codebase into isolated components.
> These can be pretty large—the Linux kernel has 16 million lines of code—but
> if your codebase is many times larger than a complete modern kernel, you
> might want to split it.

As part of a company that switched to same kind monorepo structure form
several separate repositories - there is nothing "pleasant" about having to
deal with multiple Git repositories for connected components. Subtrees,
submodules are utter hell of maintenance, checkout bugs (which hurt CI) and
bad UX across the board ("why doesn't this build?" "you forgot to checkout
submodules" "no you forgot to move the commit pointer" "no you forgot to
change dependant tests because you didn't see them in an isolated
repository"...)

It's not a GOOD approach, but it's the best approach compared to all other
more terrible ones.

~~~
woodrowbarlow
does anyone know if mercurial is more pleasant in this regard?

~~~
e12e
No, not really. Apart from the reply above about bitkeeper, I'm not aware of
any new or old (d)vcs that does "sub-modules" well.

There's AFAIK been some orgs working on mercurial in order to support large
mono-repos - I don't know if it's better or worse than git today. I see that
Illumos (opensolaris) have shifted from mercurial to git, for example:

[https://wiki.illumos.org/display/illumos/Mercurial+Workflow](https://wiki.illumos.org/display/illumos/Mercurial+Workflow)

(Solaris/Sun was a somewhat early adopter of "big" mercurial repos).

Working with big mono repos are not without challenges:
[https://code.facebook.com/posts/218678814984400/scaling-
merc...](https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-
facebook/)

FWIW I tried using sub-modules for mercurial some years ago - in the end I
realized it was probably not worth it. I'm also skeptical about go's use of
"vendoring" dependencies for a similar reason.

------
jpsim
It's a little funny that GVFS itself is hosted on GitHub which means you won't
be able to pull it as a GVFS repo.

~~~
Stratoscope
That makes perfect sense; they want the code to be where the people are.

And the GVFS repo doesn't have the problems GVFS tries to solve. The current
.git directory is only 425KB. You could put three copies on a floppy disk!

------
whatnotests
I recall that for Windows "Longhorn" they were supposed to include a file
system based on SQL Server.

Never happened. We ended up with "Vista" instead.

Maybe they've learned their lessons on that.

I do recall some years ago seeing someone had posted (here maybe?) that they
were using git to manage their home directory and everything in it.

Having the ability to easily switch between versions of my operating system
could possibly be great.

    
    
      git checkout -b upgrade/service-pack-12
      # ...trying things...
      # ..decide it was a terrible idea...
      git reset --hard
      git checkout -
      # phew!

~~~
sigi45
You can do that with nixos.

Anyway when the said this about a File System based on SQL Server, i really
liked the idea. I had something similiar in my head: Instead of installing
software to folders, you add a node and all necessary files are referenced in
this node.

That is basicly what apps are doing right now already. But imagine that your
folders become tags and meaning and when you put images into a 'year' or in an
'event' node they are already sorted.

~~~
nolok
> But imagine that your folders become tags and meaning and when you put
> images into a 'year' or in an 'event' node they are already sorted.

You might be interested by this:

[http://stackoverflow.com/a/3263550](http://stackoverflow.com/a/3263550)

In particular, Tagistant allows things such as:

$ ls ~/myfiles/store/photos/@/London/

$ ls ~/myfiles/store/pictures:/aperture/gt/5.6/@

$ ls ~/myfiles/store/time:/hour/lt/3/@

etc ...

~~~
sigi45
I will have alook :). In generall it would have been awesome if MS would have
done it on a broad spectrum.

------
koolba
Anybody know what CLI the Microsoft git users use on Windows? The few times
I've tried using GitBash it's been _very_ slow. Not unworkable, but painfully
slow.

~~~
trentnelson
The WSL git. I used to use the cygwin git, but WSL is much faster. I use
quirky ssh hostnames (gh:tpn/foo) + keychain/agent stuff so it's better suited
to WSL/cygwin than the native Windows git via cmd.exe/PowerShell.

------
comex
I wonder how hard it would be to port the same client code to also run under
FUSE on Linux/Mac. For this to take off outside of Microsoft, it needs
universal client support.

~~~
kyrra
Someone at Google created an unofficial project that does something similar to
GVFS. It's a bit more limited as it was focused around Android's use case, but
it seems like it could be a good base?

[https://github.com/google/slothfs](https://github.com/google/slothfs)

------
grandalf
It would be interesting to use this not only for the filesystem but for the
entire OS, so that all state changes could be audited. Perhaps some unikernels
already do this sort of thing.

~~~
dexwiz
It sounds like GVFS solves the problems of big repos by only fetching and
diffing files you actually need. It might handle a 300GB repo, but its does
this by only working with the 1GB of the repo you actually use, and
"virtualizing" the rest. If you pulled down the full 300GB repo then it would
suffer from the same issues as a vanilla git repo.

GFVS isn't really a file system like NTFS or ext3. It's a way to work with a
subset of a git repo in a flexible manner (not submodules).

~~~
shakna
Could this be integrated with Windows for a more streamlined experience
though?

Use GVFS instead of Windows Updates when you need a new driver or the latest
.Net framework.

Windows itself is already in a giant git repo, only pull the features you
need?

A smaller OS could remove some of the pain points of small SSDs and the like
with cheap consumer devices, and Windows Updates can be rather finnicky at
times.

------
ploxiln
Embrace and Extend, anyone?

(I don't expect anything nefarious, Microsoft doesn't have the power these
days to make GVFS the default git client for 90% of developers, it's just
amusingly MS style...)

~~~
deelowe
2002 was over 10 years ago. This meme has run it's course. It's pretty clear
MS has a different strategy these days, which makes sense. The market is
totally different.

~~~
harry8
2016 was last year.

There is no point complaining than an earned and deserved reputation is earned
and deserved.

~~~
harry8
Sorry, I should point out it is not a "meme" whatever the hell that is. It was
(and we have no evidence whether it still is) Microsoft policy. As found by
the US DOJ. They've probably stopped using the term internally, which I
believe because I don't think MS execs are stupid.

[https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish](https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish)

Not a meme. An earned and deserved reputation. I'm sure Microsoft don't like
their reputation and that's kind of the point.

