4 ms·

14 is not the public (marketing) name, it's our internal version number. The currently shipping version, as you note, is version 12 (internally), but is called

14 is not the public (marketing) name, it's our internal version number. The currently shipping version, as you note, is version 12 (internally), but is called Visual Studio 2013 on the box. There is not necessarily a relationship between the version number that is used internally and the version number as described my marketing. I don't think we've made any public statements about "why 14", but I'm sure that you can draw your own conclusions as to why we jumped from 12 to 14 without a 13 in the middle. (ObDisclaimer: I work on the Visual Studio TFS team.)

TheAnimus 12y ago
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.
- ethomson 12y ago
  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.
  - louthy 12y ago
    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.
    - ethomson 12y ago
      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.)
Renaud 12y ago
If they skipped the 13 out of superstition, they should also skip 14, it doesn't bode well in Asia where in some countries, buildings often don't have any floor numbered 4, 13, 14, 24... not that these floors don't physically exist of course, these numbers are just not used. Tretraphobia it's called, and it's a serious thing: http://en.wikipedia.org/wiki/Tetraphobia http://en.wikipedia.org/wiki/Tetraphobia

TheAnimus 12y ago

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.

ethomson 12y ago
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.
- louthy 12y ago
  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.
  - ethomson 12y ago
    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.)

Renaud 12y ago

If they skipped the 13 out of superstition, they should also skip 14, it doesn't bode well in Asia where in some countries, buildings often don't have any floor numbered 4, 13, 14, 24... not that these floors don't physically exist of course, these numbers are just not used. Tretraphobia it's called, and it's a serious thing: http://en.wikipedia.org/wiki/Tetraphobia http://en.wikipedia.org/wiki/Tetraphobia