An open-source cross-platform virtual file system API that was also fast (as opposed to FUSE) would be amazing.
(a) the result of the work of a major Git player like GitHub, and a major software company like Microsoft, with tens of excellent engineers devoted on it, and that solves a real pain point they have, is a centralized abomination that merely replicates a feature SVN already had
(b) your description is a crude knee jerk reaction
?
If SVN is a terrible application with no merits to large developers like MS, why did it exist in the first place?
If the features SVN brings over git are not considered detrimental by Torvalds, why did he create his own VCS with them removed, and why hasn't he added them back in?
Where's the contradiction? All kids of terrible apps exist. Terribleness and existence are not mutually exclusive qualities.
(Assuming SVN is terrible, of course, which I didn't say. I'd say SVN was a attempt to go beyond CVS with some shortcomings that don't make it the best available option today).
>If the features SVN brings over git are not considered detrimental by Torvalds, why did he create his own VCS with them removed, and why hasn't he added them back in?
Lots of possible answers (given the assumption in your "if"):
E.g. he might not consider them detrimental for other people and use cases, but he doesn't need them for his use case (Linux kernel development) either.
Or he thinks that while they might be good, they complicate things too much, and he prefers a more minimum feature set.
Microsoft decided to stick with git but add non-strict fetching to it. On the plus side, still all the advantages of easy branching/merging and working offline if you touched the required files which distributed vcs's bring. But you still need to be connected to work with parts of the code base you haven't used before.
So I guess if you run the test suite for your current task first then you can work offline since all relevant files will be fetched?
Which seems like a fair tradeoff to me. The existing "native solution" for a very very large codebase would be to have it split into multiple, logical repositories. If you fetched one repo you needed to work on, but not all the dependencies or sibling repos, you still wouldn't be able to work on those other parts of the codebase until you connected.
Compared to mercurial, that Facebook uses?
https://code.facebook.com/posts/218678814984400/scaling-merc...
I was pretty surprised when I made my own build of OpenJDK 9 how easy it was to work with, `hg tclone blah`, `hg tup jdk9.0.1+11`, `./configure blah; make images` and done. Even if git submodules were closer in functionality (checking out the same tag across multiple modules at once with ease) the song-and-dance with actually downloading the modules after cloning is annoying.
Even if a CDN is more "hierarchical" rather than P2P, it's still distributed, it's just distributed on a different axis than you are perhaps expecting.
Furthermore, to a very large extent that's an implementation detail. The GVFS protocol itself [1] is a very simple REST API, and there is absolutely nothing stopping you from building a GVFS "server" that is literally backed by IPFS or BitTorrent or some other P2P file system.
[1] https://github.com/Microsoft/gvfs/blob/master/Protocol.md
- X software package name reminds/confuses me of Y product with similar name
- X title is garbage. Here is the title I would write...
- I don't understand [basic concept available on Wikipedia]. Someone explain it to me (aka lazyweb)
- I'm not an expert on this, but [completely unqualified and uncited conjecture]
- I also once did X from TFA and [unrelated personal anecdote with no insight] (aka long form "me too" comment)
I come to HN so that I can read informed discussion from people who work in the field of TFA. To read discussion of basic topics between the uninformed, there is everywhere else on the internet.
Has infected the hell out of our company Slack. It's considered very rude to not answer.
I feel like when I was coming up, where IRC or mailing lists were a thing, having done all possible research before asking humans was an absolute cultural requirement.
It sucked at first, but I definitely miss that and long for the old days. It was so much more respectful and efficient.
Sure, in some cases, implementation of this policy fails, and something is rewritten that shouldn't be, or something should be rewritten that isn't. But, I'd estimate maybe 80% of all discussions about titles, that I've seen, have been valid concerns, and typically resulted in a rewrite.
- this project/library/company name is terrible
- this website hijacks my scroll bar
- this website doesn’t render well in mobile
- I can’t read this site because it’s too narrow
- I can’t read this site because it’s too wide
It defines a "CDN protocol" for downloading those objects as needed (which Bitbucket and GitHub are both supporting in various alpha/beta stages), which is essentially a cache offered as a paid service to big enterprise projects, but the GVFS project also has to make sure that git operates as efficiently as possible with sparse object databases, and implements how those sparse object databases work at all (which to this point was not something git concerned itself with, and partly why the work is being done as a filesystem proxy using placeholder files on the user's machine).
The project has included work in making sure that git commands touch as few objects from the object database as they can to get their work done (minimizing downloads from a remote server).
This style of working is needed in large code bases, where not all files are checked out on developer workstations (for performance or privacy reasons).