7 ms·

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 Faceb

by kentt 10y ago

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.

anon987 10y ago
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.
- testUser69 10y ago
  Shhhhh! It's Microsoft, we're not allowed to have a negative opinion of anything they do on hacker news.
  - SippinLean 10y ago
    The recent Windows 10 thread was full of criticism for MS
    - floopidydoopidy 10y ago
      And full of down votes for the negative comments. This website is very pro successful business, not pro tech.
      - deleted 10y ago
        [deleted]
      - testUser69 10y ago
        Exactly, the top comment in this thread claims MS is the only company doing cool things (which is 100% not true). The top comments in the Windows 10 thread yesterday were mostly people claiming "it's sad to see such negativity toward MS" and there was maybe one or two negative comments followed by a circle jerk about how good MS and their software is. Microsoft has historically been one of the worst tech companies for tech enthusiasts. We can ignore all the awful things they did in the 90's that stifled open standards (because apparently that doesn't matter anymore?) and just look at 2013, when they were exposed to have been participating in the NSA PRISM project. That means there is a whole team at MS that worked on a secret government project to help violate our fourth amendment rights. Even much of congress didn't know about NSA mass data collection, but Microsoft did. People who trust MS these days are either naive or employed by them.
  - sctb 10y ago
    We've already asked you to please stop this, so we've banned the account.
- nine_k 10y ago
  If you deal with code, the case is marginal for you. If you deal with graphics, audio assets, etc, the binary-blob type of data, the case is central.
  - aanm1988 10y ago
    This is about code, and code history. Just insane volumes.
- sebastos 10y ago
  "I don't have this problem, so nobody does." Lacking support for large binary blobs is, like, THE #1 reason that an engineer might have to use an alternative.
- rplnt 10y ago
  Well it's a problem for thousands of employees of Microsoft, isn't it? We've had much smaller repository (10GB IIRC) and it really was annoying how long everything took, even with various caches and what not enabled.
- ska 10y ago
  How many people have that problem, really? An easy lower bound is 10s of thousands of engineers : developers at several large tech companies (e.g. MS, facebook, google, ?)
- aanm1988 10y ago
  It's not a caching layer, it's lazy evaluation.
- daxelrod 10y ago
  Ok, but you'll encounter similar git limitations with repos several orders of magnitude smaller than that too. All you need is several hundred engineers and your monorepo becomes unwieldy for git to handle.
mox1 10y ago
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-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...
- jbergens 10y ago
  They did a couple of months ago so I assume they still do.
- kyrra 10y ago
  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 https://www.mercurial-scm.org/repo/hg [1] https://www.mercurial-scm.org/wiki/4.2sprint https://www.mercurial-scm.org/wiki/4.2sprint
  - durin42 10y ago
    Sprints are twice a year, once in the US and once in Europe.
- janwh 10y ago
  They do. Durham Goode (Tech Lead on Source Control at Facebook) just held a talk at Git-Merge about how they scaled Mercurial at Fb. They seem to be quite happy with it, albeit applying quite a few restrictions on their internal users that are not really transferable to the general (outside-corporate) usage of VCS (for example only rebases are allowed, directly committing to master all the time, etc.)
  - durin42 10y ago
    That's actually pretty comparable to how we tend to operate the Mercurial project, FYI. We tend to prefer rebase to merge for feature work.
outcoldman 10y ago
Also don't think that this is a good idea. Git is a Distributed Version Control https://en.wikipedia.org/wiki/Distributed_version_control https://en.wikipedia.org/wiki/Distributed_version_control, the main benefit of which is "allows many software developers to work on a given project without requiring them to share a common network". Seems like with GVFS they are making DVC to be a CVS (https://en.wikipedia.org/wiki/Concurrent_Versions_System https://en.wikipedia.org/wiki/Concurrent_Versions_System) again. What is the point? There are a lot of good CVS systems around. They just to give cool kids access to cool tools? I believe there are plenty bridges between CVS and git already implemented, which also allows you to checkout only part of the CVS tree. At Splunk we had the same problem, our source code was stored in CVS (perforce), but we wanted to switch to git. And not only because we really wanted to use git, but to simplify our development process, mainly because of the much easier branching model (lightweight branching also is available in perforce, but to get it we still needed to do some upgrades on our servers). We also had a problem that at the beginning we had very large working tree, don't think it was 200-300Gb, I believe it was 10x less, and actually required 4-5 seconds for git status. This was not appropriate for us, so we worked on our source code and release builds to split it in several git repos to make sure that git status will take not more than 0.x seconds. My point is use right tools for right jobs. 4-5 seconds for git status is still a huge problem, I would prefer to use CVS instead if that will not require me to wait 5 seconds for each git status invocation.
- klodolph 10y ago
  > I believe there are plenty bridges between CVS and git already implemented, which also allows you to checkout only part of the CVS tree. How many of them have you used? I've used a couple, to interact with large code bases on the rough order of 300GB. In my experience they don't work very well, because you have to be hygienic about the commands you run or some part of your Git state gets out of sync with some part of your state for the other source control system. So I gave up on those, and I use something similar to Microsoft's solution at work on a daily basis. It's a real pleasure by comparison, and in spite of that I still call myself a Git fan (about 10 years of heavy Git use now). At work the code base is monolithic and everyone commits directly to trunk (at a ridiculous rate, too). I've heard horror stories about back when people had to do partial checkouts of the source code, and I'm glad that the tooling I use is better. The idea of breaking up a repository merely because it is too large reminds me the story of the drunkard looking for his keys under the streetlights. The right tools for the right job, sometimes you change the job to match the tools, and sometimes you change the tools to match the job.
youdontknowtho 10y ago
I was actually surprised that there was only as much negative sentiment as there is. Microsoft could cure cancer and the post to HN would be mostly negative. It's tribal. It doesn't even matter what they do at this point. That being said, you can see more and more people getting off the "Microsoft is evil" train. It's super slow and every bone headed thing that Microsoft does resets the needle for lots of people. I've always been surprised how much sympathy a company like IBM or Intel gets on HN. They both sue people over patents. That both contribute to non-free software. They were early backers of Linux, though, and that is what people care about superficially.
- floopidydoopidy 10y ago
  This is just more of their embrace, extend, extinguish campaign. This is the extend part.
  - youdontknowtho 10y ago
    yep. you got it one, wiley coyote.
- jjjingleheimer 10y ago
  to be fair, i cant say that i care if people are fair to a multinational corporation. whether linux fans are right or not they are still only doing whats best for their bottom line. should a company get a trophy for doing what its customers want?
  - youdontknowtho 10y ago
    that's a good point. its funny, though, that they have actually started doing a lot of things for PR purposes that i van only imagine that most of their customers couldn't really care less about. for example, the majority of their money still comes from windows and office, but open source and hologram BS impress the most vocal anti-MS voices in the media. my point, though, is that there are other companies that dont draw nearly as much ire that engage in the exact same practices. i think, that early antagonism between MS and Linux users has become a tribal signifier for some people. Microsoft people used to have the same kind of relationship with IBM. They also kept flogging that longer than it really made sense...just like linux and mac fans.
ajross 10y ago
> This is a great idea and solves a real problem for a lot of use cases. I don't know if "a lot" is the right qualifier. Solitary repos of millions of files have scalability problems even outside the source control system (I mean: how long does it take your workstation to build that 3.5 million-file windows tree?) A full Android system tree is roughly the same size and works fine with git via a small layer of indirection (the repo tool) to pull from multiple repositories. A complete linux distro is much larger still, and likewise didn't need to rework its tooling beyond putting a small layer of indirection between the upstream repository and the build system. Honestly I'd say this GVFS gadget (which I'll fully admit is pretty cool) exists because Microsoft misapplied their source control regime.

by kentt 10y ago

anon987 10y ago

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.

testUser69 10y ago
Shhhhh! It's Microsoft, we're not allowed to have a negative opinion of anything they do on hacker news.
- SippinLean 10y ago
  The recent Windows 10 thread was full of criticism for MS
  - floopidydoopidy 10y ago
    And full of down votes for the negative comments. This website is very pro successful business, not pro tech.
    - deleted 10y ago
      [deleted]
    - testUser69 10y ago
      Exactly, the top comment in this thread claims MS is the only company doing cool things (which is 100% not true). The top comments in the Windows 10 thread yesterday were mostly people claiming "it's sad to see such negativity toward MS" and there was maybe one or two negative comments followed by a circle jerk about how good MS and their software is. Microsoft has historically been one of the worst tech companies for tech enthusiasts. We can ignore all the awful things they did in the 90's that stifled open standards (because apparently that doesn't matter anymore?) and just look at 2013, when they were exposed to have been participating in the NSA PRISM project. That means there is a whole team at MS that worked on a secret government project to help violate our fourth amendment rights. Even much of congress didn't know about NSA mass data collection, but Microsoft did. People who trust MS these days are either naive or employed by them.
- sctb 10y ago
  We've already asked you to please stop this, so we've banned the account.
nine_k 10y ago
If you deal with code, the case is marginal for you. If you deal with graphics, audio assets, etc, the binary-blob type of data, the case is central.
- aanm1988 10y ago
  This is about code, and code history. Just insane volumes.
sebastos 10y ago
"I don't have this problem, so nobody does." Lacking support for large binary blobs is, like, THE #1 reason that an engineer might have to use an alternative.
rplnt 10y ago
Well it's a problem for thousands of employees of Microsoft, isn't it? We've had much smaller repository (10GB IIRC) and it really was annoying how long everything took, even with various caches and what not enabled.
ska 10y ago
How many people have that problem, really? An easy lower bound is 10s of thousands of engineers : developers at several large tech companies (e.g. MS, facebook, google, ?)
aanm1988 10y ago
It's not a caching layer, it's lazy evaluation.
daxelrod 10y ago
Ok, but you'll encounter similar git limitations with repos several orders of magnitude smaller than that too. All you need is several hundred engineers and your monorepo becomes unwieldy for git to handle.

mox1 10y ago

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-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...

jbergens 10y ago
They did a couple of months ago so I assume they still do.
kyrra 10y ago
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 https://www.mercurial-scm.org/repo/hg [1] https://www.mercurial-scm.org/wiki/4.2sprint https://www.mercurial-scm.org/wiki/4.2sprint
- durin42 10y ago
  Sprints are twice a year, once in the US and once in Europe.
janwh 10y ago
They do. Durham Goode (Tech Lead on Source Control at Facebook) just held a talk at Git-Merge about how they scaled Mercurial at Fb. They seem to be quite happy with it, albeit applying quite a few restrictions on their internal users that are not really transferable to the general (outside-corporate) usage of VCS (for example only rebases are allowed, directly committing to master all the time, etc.)
- durin42 10y ago
  That's actually pretty comparable to how we tend to operate the Mercurial project, FYI. We tend to prefer rebase to merge for feature work.

outcoldman 10y ago

Also don't think that this is a good idea. Git is a Distributed Version Control https://en.wikipedia.org/wiki/Distributed_version_control https://en.wikipedia.org/wiki/Distributed_version_control, the main benefit of which is "allows many software developers to work on a given project without requiring them to share a common network". Seems like with GVFS they are making DVC to be a CVS (https://en.wikipedia.org/wiki/Concurrent_Versions_System https://en.wikipedia.org/wiki/Concurrent_Versions_System) again. What is the point? There are a lot of good CVS systems around. They just to give cool kids access to cool tools? I believe there are plenty bridges between CVS and git already implemented, which also allows you to checkout only part of the CVS tree. At Splunk we had the same problem, our source code was stored in CVS (perforce), but we wanted to switch to git. And not only because we really wanted to use git, but to simplify our development process, mainly because of the much easier branching model (lightweight branching also is available in perforce, but to get it we still needed to do some upgrades on our servers). We also had a problem that at the beginning we had very large working tree, don't think it was 200-300Gb, I believe it was 10x less, and actually required 4-5 seconds for git status. This was not appropriate for us, so we worked on our source code and release builds to split it in several git repos to make sure that git status will take not more than 0.x seconds. My point is use right tools for right jobs. 4-5 seconds for git status is still a huge problem, I would prefer to use CVS instead if that will not require me to wait 5 seconds for each git status invocation.

klodolph 10y ago
> I believe there are plenty bridges between CVS and git already implemented, which also allows you to checkout only part of the CVS tree. How many of them have you used? I've used a couple, to interact with large code bases on the rough order of 300GB. In my experience they don't work very well, because you have to be hygienic about the commands you run or some part of your Git state gets out of sync with some part of your state for the other source control system. So I gave up on those, and I use something similar to Microsoft's solution at work on a daily basis. It's a real pleasure by comparison, and in spite of that I still call myself a Git fan (about 10 years of heavy Git use now). At work the code base is monolithic and everyone commits directly to trunk (at a ridiculous rate, too). I've heard horror stories about back when people had to do partial checkouts of the source code, and I'm glad that the tooling I use is better. The idea of breaking up a repository merely because it is too large reminds me the story of the drunkard looking for his keys under the streetlights. The right tools for the right job, sometimes you change the job to match the tools, and sometimes you change the tools to match the job.

youdontknowtho 10y ago

I was actually surprised that there was only as much negative sentiment as there is. Microsoft could cure cancer and the post to HN would be mostly negative. It's tribal. It doesn't even matter what they do at this point. That being said, you can see more and more people getting off the "Microsoft is evil" train. It's super slow and every bone headed thing that Microsoft does resets the needle for lots of people. I've always been surprised how much sympathy a company like IBM or Intel gets on HN. They both sue people over patents. That both contribute to non-free software. They were early backers of Linux, though, and that is what people care about superficially.

floopidydoopidy 10y ago
This is just more of their embrace, extend, extinguish campaign. This is the extend part.
- youdontknowtho 10y ago
  yep. you got it one, wiley coyote.
jjjingleheimer 10y ago
to be fair, i cant say that i care if people are fair to a multinational corporation. whether linux fans are right or not they are still only doing whats best for their bottom line. should a company get a trophy for doing what its customers want?
- youdontknowtho 10y ago
  that's a good point. its funny, though, that they have actually started doing a lot of things for PR purposes that i van only imagine that most of their customers couldn't really care less about. for example, the majority of their money still comes from windows and office, but open source and hologram BS impress the most vocal anti-MS voices in the media. my point, though, is that there are other companies that dont draw nearly as much ire that engage in the exact same practices. i think, that early antagonism between MS and Linux users has become a tribal signifier for some people. Microsoft people used to have the same kind of relationship with IBM. They also kept flogging that longer than it really made sense...just like linux and mac fans.

ajross 10y ago

> This is a great idea and solves a real problem for a lot of use cases. I don't know if "a lot" is the right qualifier. Solitary repos of millions of files have scalability problems even outside the source control system (I mean: how long does it take your workstation to build that 3.5 million-file windows tree?) A full Android system tree is roughly the same size and works fine with git via a small layer of indirection (the repo tool) to pull from multiple repositories. A complete linux distro is much larger still, and likewise didn't need to rework its tooling beyond putting a small layer of indirection between the upstream repository and the build system. Honestly I'd say this GVFS gadget (which I'll fully admit is pretty cool) exists because Microsoft misapplied their source control regime.