Hacker News Reader

Comment by TheAnimus | Hacker News Reader

I really like visual studio as an IDE, but I find myself really liking some of the things in 14. vNext, removing the cruft from my current stack, Rosyln at it's least simplifying the difference between my intelisense and actual compile.

But as you are on the TFS team I feel you are a good person to ask, are there many improvements from a TFS source control perspective? It still feels 'clunky' if I want to commit and run a specific build it's laborious. Oh and lets not even ask why my visual studio online builds, with their paid azure account haven't built anything in the last 5 hours :(

I do like the ecosystem, I like an IDE that lets me do everything in one place, that is extensible enough to ensure I can od everything I need there. But the current interactions, maybe tonights downtime has made me angry, are rather disappointing.

View on HN

From a version control perspective, we're investing heavily in Git right now, which brings a DVCS ecosystem into Team Foundation Server. This means that you can choose between using a checkout/edit/checkin model (TFVC "server workspaces"), a much more relaxed edit/merge/commit model (TFVC "local workspaces") or a DVCS (Git). I hope that wasn't too marketing speak-y.

Anyway, sorry things feel clunky. I would definitely suggest moving from a server workspace to a local workspace if you haven't already and don't need some of the guarantees it makes about locking files for checkout and such. An edit/merge/commit system isn't nearly as chatty with the server and is much more pleasant to use on a daily basis.

local workspaces are hopelessly broken for repositories of any real size. They're slow, you get local store conflicts when running multiple copies of VS, etc. Server workspaces are a pretty poor solution if you have remote workers on poor connections.

So far Git integration seems good, but I have only used it on some smaller projects.

Here's a moaning email I sent to a few devs I work with in April re: TFS:

"...In the office it's slightly better, but TFS is still slow. This is just the tip of the iceberg with TFS though.

Open TFS explorer - 20-30 seconds

Open a folder in TFS explorer - 20-30 seconds

Rename a file - forget it, go and get a coffee

Add a file - forget it, go and get a coffee

Delete a file - forget it, go and get two coffees

Edit a file - Often I see "Waiting for a required operation to complete..." -- see below

Then when you add into the mix that I'm on Virgin media who are the shittest internet provider on earth and who clearly do traffic-shaping on VPN connections; and they constantly drop my VPN connection, which will cause TFS to lock-up -- you might start to see why I'm going slightly insane.

Yet when I work on a pet open-source project with Git everything is sweetness. It seems like the Visual Studio team just started again with their Git integration. It doesn't even have to reload projects when you sync and a project file has changed, it just happily merges it in.

Ultimately even if we host TFS on the best server known to man, I won't ever get over the fact that Virgin media are going to be constantly fucking me over. So a local-store makes much more sense. TFS has a local-store mode, but (incredibly!) its performance is worse than the server version. It seems to be because our store is too large for it (over 100,000 files).

I think it just goes to show how awful TFS is if they can't even create a local database which can manage 100,000 files.

I see this error all the time (on VS 2012 and VS 2013):

[Picture of the 'Waiting for required operation to complete dialog']..."

Sorry if I'm bitching about your work, but it seems the Git integration is the only real game in town right now. It really is very impressive compared to the other options.

Unfortunately I can't really provide advice for your local workspace troubles as I work on the Git side of things.

I'm sorry to hear about your performance troubles with local workspaces: 100,000 files in a local workspace should not be at the upper limits, I wouldn't think. Many people 'round these parts were using local workspaces for their VS 2013 development: my working folder mappings appear to be 25 GB and 120,000 files for VS 2013. Concurrency and locking, of course, could affect that, but I'm still surprised.

I trust you're not doing anything wacky like trying to put your working folders on USB sticks or SMB mounts, so I would recommend either opening a question on the MSDN support forum or (better) opening a support ticket. Our support engineers are really quite good and might be able to assist, or at least understand why you're seeing this performance with local workspaces.

(I regret that we cannot fix your internet provider.)

Heh, thanks for the response :) I realise you can't do anything for me, I just thought I'd give you a sense of the frustration of the local-workspace route. The fact it's slower and less reliable than the server-workspace approach is pretty crazy.

> I trust you're not doing anything wacky like trying to put your working folders on USB sticks or SMB mounts

Nothing crazy, repository is sitting on an SSD drive.

If you're working on the Git side, then all I can say is: great job! I'm hoping to move our source repository over Git soon... I can't handle staying with server/local workspaces much longer, but as with all things like this it's about finding the right moment for the team to switch.

Reply on news.ycombinator.com