* Posts by bharry_msft

2 publicly visible posts • joined 9 Feb 2016

Microsoft foists fake file system for fat Git repos

bharry_msft

Actually Team Foundation Server and Visual Studio Team Services both support Git hosting (and the GVFS protocol). So they aren't going away - just getting better.

On the issue of removing the "D" from DVCS, I think we need to explain that better. I'll work on that but I'll give a short answer here. We're not removing the "D" at all. On the server, at least, it's just GIt (with a few very small restrictions lie end of line translation). You can connect to it with any Git client and it has every single property Git has. That same repo that you can use a normal Git tool against, you can also use a GVFS enabled client against. You choose. Now, if the repo is big enough, you might choose to use the DVFS client. It still retains all Git semantics - except, if you go offline, you only have access to what you've cached locally. If you've already cached everything you need, you are golden. Over time, I thnk we can look at adding tools for managing what is cached even for people with really big repos who what to disconnect.

Regardless of whether you disconnect or not, though, all the Git versioning behavior and the ability to create remotes to enitely unrelated repos, etc. are still there. It's just Git with the ability do download stuff on demand and a ton of performance improvements. And if you don't like it, don't enable GVFS and just use Git without GVFS. Your choice.

Brian Harry

Microsoft

Scary RAM-gobbling bug in SQL Server 2014 exposed by Visual Studio online outage

bharry_msft

Query optimizers

I've been working around query optimizers for a long time and one of the things I've learned is that they are rocket science. They are incredibly difficult to get right and a small change that improves one query can affect others negatively. That's part of why SQL Server gives you the ability to control (through trace flags) which query optimizer compat level you are using. You should never change the compat level on a large scale database without testing. As I said in my post, the responsibility for this outage it mine, not SQL's. Yes their new cardinality estimator misestimated this query. They will tune it to fix this query while keeping the millions of others working well. This is the business of query optimization. I view part of my job as a large scale Microsoft service as providing a great test case for our platform services. As some of you have surmised the issue is with intermediates, not with the result. So the top 1 alone isn't enough to tell the estimator the answer - I should have mentioned that in my post. I truly believe, there's no incompetence on the SQL Server side - and I'm not just saying that because I work at Microsoft. Those folks do some amazing things and I'm grateful for it.

Brian Harry