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

261–270 of 287 posts

Re: Announcing GVFS: Git Virtual File System

#261

Post by lnguyen »

sdesol wrote: post #260
sdesol wrote: post #233

Earlier quoted context omitted.

If they get this right, this can be MASSIVE for Microsoft in Enterprise. ClearCase was the reason why IBM was able to charge $1000+ per developer license fees. ClearCase did what a lot of Enterprise companies needed at the time, and most importantly, it created hooks, that were mostly too difficult to remove. Once you create deep integration with ClearCase, you are very much committed to using it long term.

I was planning on responding to the person that had replied, but their comment has since been removed, and because I can't edit my post, I'll add some insight, as to why I used ClearCase as an example. For those who have never worked with/administered ClearCase before, you may not fully appreciate how insanely complex it is. In order to use it, you first have to apply kernel patches from IBM, which shows how committe…

My "favorite" Clearcase server issue was one that took 2 weeks of uptime before it resulted in a crash on a up-to-date AIX installation. I had to wait until we had somewhat identified the timeline before engaging our ops team so they could log the crash and submit it back to IBM so they could investigate/fix

Re: Announcing GVFS: Git Virtual File System

#262

Post by christophilus »

general_ai wrote: post #234
mooman219 wrote: post #227

Earlier quoted context omitted.

Google employs a distributed, caching, incremental build system and a distributed test system across the majority of their code base. I worked in Windows Store and I can assure you that most people there don't use CloudBuild and CloudTest, let along know what they are. I would be confident in saying the majority of people at Microsoft are in that boat.

+1. I know some insiders at MS and their build/test/deployment story is universally very crappy. Things barely work, held together by curse words and duct tape. Googlers like to joke internally that Google looks like a race car from the outside and like Moving Castle from Hayao Miyazaki'a cartoon from the inside, but that's not the case at all. Comparatively speaking it's a race car inside and out, it's just that the…

I worked in the cloud at MS roughly 7 years ago, and Bing was very different from anything else. The MS cloud services were a total mess. I mean, as in hard to overstate how bad. In contrast, Bing was a well-oiled machine. Simple build, simple deploy, simple devops, simple test, very consistent processes across all of their teams.

At the time, Azure was a joke (partly due to the fact that the initial teams were headed up by ex Office devs with no cloud experience, if I remember correctly). But Azure was cannibalizing the Bing team pretty hard. I hear that strategy worked and that Azure is in much more capable hands now.

Re: Announcing GVFS: Git Virtual File System

#263

Post by shandor »

Groxx wrote: post #182
zahreeley wrote: post #158

Don't believe in modular development with smaller repos?

Yeah, I see things like this, and I always wonder why they don't make a submodule tree. It wasn't an option a couple years ago, but submodules work fine now. With a little bit of scripting to wrap common uses, they're practically pain-free.

Could you elaborate a little what has changed there? My understanding is that submodules are still considered a mess, but would be really nice if some actual improvements have happened.

Re: Announcing GVFS: Git Virtual File System

#264

Post by david-given »

tcbawo wrote: post #248
wyldfire wrote: post #50

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 Clea…

I used Clearcase (on Solaris) in 1999 and was not a fan. It slowed our build times by at least 10x. I'm sure it was probably set up wrong, but this was a Fortune 100 company with lots of dedicated resources.

I used Clearcase a while back in an office in China. Every few days there'd be an email going round pleading with people to keep their antivirus software up-to-date; because someone had a virus somewhere, and apparently the virus would try to infect executables on the Clearcase virtual drive, at which point Clearcase would obligingly check the infected file into the VCS and distribute it to all clients...

Re: Announcing GVFS: Git Virtual File System

#265

Post by amingilani »

I'm no expert but if most single developers only use 5-10% of the codebase in their daily life, wouldn't it make to maybe break the project into multiple codebases of about 5% each and use a build pipeline that combines them together when needed?

Although I could definitely be wrong but this sounds a lot like monolith vs microservices to me.

Re: Announcing GVFS: Git Virtual File System

#266

Post by nh2 »

piotrkaminski wrote: post #238
general_ai wrote: post #215

Earlier quoted context omitted.

> perforce model is far inferior to git's That's just, like, your opinion, man. There are other bits of infra that integrate with it quite nicely, and would integrate with something like Git quite poorly. One of those things is their code review system. The closest thing I could find to it outside Google is Gerrit, but it's a tremendous pain to set up and use, and it's but a pale shadow of Google's internal tool (Cri…

Check out Reviewable, it's influenced by my fond memories of Critique but designed specifically for git (and GitHub).

Reviewable is amazing, thanks for making that.

I've used lots of review tools and worked a bit on Google's review tool and on ReviewBoard in the past, and Reviewable is better than all of them in my opinion (or at least, better than when I last used the others).

Re: Announcing GVFS: Git Virtual File System

#267

Post by daxelrod »

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.

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.

Re: Announcing GVFS: Git Virtual File System

#268

Post by ianopolous »

kevincox wrote: post #211
ianopolous wrote: post #52

Couldn't they use git over IPFS?

No. The problem isn't only the storage or fetching of the files (this is the easy bit :) ), it's the operations that detect changes in the working tree. If you have a large tree scanning it becomes slow. Using a vfs allows you to track which files have changed so that these operations no longer need to scan. Now they are O(changed files) which is generally small. Now IPFS has a vfs, but it is just a simple read/write…

IPFS clearly does a lot more than storing and fetching files. Seriously, go have a read. A single hash can represent an arbitrarily large subtree of data (Microsoft's entire repo). Using an IPLD selector (in its simplest form, a path beyond the hash) an arbitrary sub component can be addressed. This can be used to avoid scanning entire subtrees (maintaining your O(changed files)). To commit your modifications is O(changed files + tree depth to the root of your modifications) you never need to do anything with the rest of the repo.

For tracking changes (i.e. mutable data) you can use IPNS and create a signed commit history. This will be built on IPFS eventually so it's only a matter of time.

Re: Announcing GVFS: Git Virtual File System

#270

Post by asveikau »

general_ai wrote: post #254
haberman wrote: post #241

Earlier quoted context omitted.

Just to give others an idea of what this is like: I work on the Protocol Buffers team at Google. Almost all software at Google depends on my team's code. If I have a pending change, I can test it against the whole codebase before submitting (this is a "global presubmit"). If something breaks in global presubmit, I can build and run any target in the codebase with my change in a single command, and this will take O(10…

Dunno how it is now, but years ago it'd take them a _few weeks_ to just propagate commits into the stable branch through a series of elaborate branch integrations, so yeah, you couldn't change something and test it on a whim. Plus build of just windows alone would take overnight, and rebuilding everything to test a Windows change was not logistically, politically, or technically possible.

> you couldn't change something and test it on a whim

You could. It would just not leave your branch for a while. Around the scheduled merges it would run against the tests of progressively more of the larger organization.

Parts of this actually constituted a good way to prevent being distracted by the bugs of faraway teams. If something reached your branch, where you were working, it was vetted by the tests required to make it into winmain.

The downside was that people got fairly political about what goes into the branch and when, even for small things.

Post reply on HN