3 ms·

I know, and it shows. This is exactly what the VS/TFS/Azure team must stop doing. Edit: I can't reply to your comment for some reason. If they do use their own

by Flow 14y ago

I know, and it shows. This is exactly what the VS/TFS/Azure team must stop doing. Edit: I can't reply to your comment for some reason. If they do use their own tools, how come it's so easy to get insane merging problems on so many of the xml files in use by a VS project? Especially the .dbml files, but also the project files. :-(

ethomson 14y ago
Both the Visual Studio and TFS teams use, obviously, TFS for version control. Parts of the TFS team are using git and some of the team is using git-tf, but mostly it's straight up TFVC. But the VS and TFS teams do not use source depot (the aforementioned internal-only perforce-like tool.) Edit: as for merging XML files -- TFVC uses a standard automerge algorithm, very similar to the one git uses. I'm not sure why you're having merge problems with your XML files, but I'm also not sure it's TFS's fault. But it would be interesting if you filed a connect bug for us to take a look at!
j_s 14y ago
.dbml files are a pain to merge because on any change, that element is moved to the bottom. To avoid other people smashing my changes I manually move it back to where it was before checking in, so the diff is only one or two lines. No one else on the team does this though, so they still run into problems. I tried to find where the 'Startups for the Rest of Us' AuditShark guy (Mike?) talks about writing a tool so that his outsourced devs wouldn't have to deal with it, but it would take me too long to find. He doesn't seem like the type to believe in open sourcing anything but I wish he would consider it.
ryanmolden 14y ago
As I have said (here) before, MS is a massive company so anyone making as statement like "MS does X" is almost assuredly wrong. Devdiv, to my knowledge, as a whole (VS, CLR, etc..) uses TFS. The fork of Perforce the original commentor is talking about is probably Source Depot. When I started at Microsoft we (VS) were still using Source Depot. As I understand it the primary reason was because we had been using it forever (okay, well back to the SLIME days) and there was a massive amount of history in there. Porting it all immediately to another source control provider was a large task. I 'fondly' remember the transition during development of VS 2010. Though to be fair the TFS team was great aboout finding/fixing issues exposed by suddenly onboarding the entire VS team and our possibly 'interesting' source control requirements. I believe Windows still uses Source Depot, likely for similar reasons (the amount of history they have in SD makes the devdiv history seem like a tiny blip). As for merging problems, I don't know. We routinely merge huge branches with hundreds of thousands of files, including many project files, other XML config files, etc.. and I don't recall many 'insane merging problems' (just your garden variety merging problems that occur with that many files). Then again I am not intimately involved in the merges (other than for occasional fire-drills on files I may have modified). I suppose it also depends on what the changes were on both side of the merge.
- yuhong 14y ago
  I wonder when exactly MS took the old SLM servers down. It was mentioned on Raymond Chen's blog that it is difficult for even employees to access source control history of Windows prior to 2000.
buckh 14y ago
The developer division has used TFS for over four years now. You can read about the scale and topology at http://blogs.msdn.com/b/buckh/archive/2012/06/08/developer-division-is-running-on-tfs-2012-rc.aspx http://blogs.msdn.com/b/buckh/archive/2012/06/08/developer-d.... Ryan was being nice when talking about the transition. We put the division through hell for a while (fall of 2008 until spring 2009), but the result was an amazingly scalable centralized version control system. Now with our full, native support for git in VS, on the server (just on the service http://tfs.visualstudio.com http://tfs.visualstudio.com for right now), and joining the community to help build libgit2 (check out the committers page), TFS also supports the best DVCS.

by Flow 14y ago

ethomson 14y ago

Both the Visual Studio and TFS teams use, obviously, TFS for version control. Parts of the TFS team are using git and some of the team is using git-tf, but mostly it's straight up TFVC. But the VS and TFS teams do not use source depot (the aforementioned internal-only perforce-like tool.) Edit: as for merging XML files -- TFVC uses a standard automerge algorithm, very similar to the one git uses. I'm not sure why you're having merge problems with your XML files, but I'm also not sure it's TFS's fault. But it would be interesting if you filed a connect bug for us to take a look at!

j_s 14y ago

.dbml files are a pain to merge because on any change, that element is moved to the bottom. To avoid other people smashing my changes I manually move it back to where it was before checking in, so the diff is only one or two lines. No one else on the team does this though, so they still run into problems. I tried to find where the 'Startups for the Rest of Us' AuditShark guy (Mike?) talks about writing a tool so that his outsourced devs wouldn't have to deal with it, but it would take me too long to find. He doesn't seem like the type to believe in open sourcing anything but I wish he would consider it.

ryanmolden 14y ago

As I have said (here) before, MS is a massive company so anyone making as statement like "MS does X" is almost assuredly wrong. Devdiv, to my knowledge, as a whole (VS, CLR, etc..) uses TFS. The fork of Perforce the original commentor is talking about is probably Source Depot. When I started at Microsoft we (VS) were still using Source Depot. As I understand it the primary reason was because we had been using it forever (okay, well back to the SLIME days) and there was a massive amount of history in there. Porting it all immediately to another source control provider was a large task. I 'fondly' remember the transition during development of VS 2010. Though to be fair the TFS team was great aboout finding/fixing issues exposed by suddenly onboarding the entire VS team and our possibly 'interesting' source control requirements. I believe Windows still uses Source Depot, likely for similar reasons (the amount of history they have in SD makes the devdiv history seem like a tiny blip). As for merging problems, I don't know. We routinely merge huge branches with hundreds of thousands of files, including many project files, other XML config files, etc.. and I don't recall many 'insane merging problems' (just your garden variety merging problems that occur with that many files). Then again I am not intimately involved in the merges (other than for occasional fire-drills on files I may have modified). I suppose it also depends on what the changes were on both side of the merge.

yuhong 14y ago
I wonder when exactly MS took the old SLM servers down. It was mentioned on Raymond Chen's blog that it is difficult for even employees to access source control history of Windows prior to 2000.

buckh 14y ago

The developer division has used TFS for over four years now. You can read about the scale and topology at http://blogs.msdn.com/b/buckh/archive/2012/06/08/developer-division-is-running-on-tfs-2012-rc.aspx http://blogs.msdn.com/b/buckh/archive/2012/06/08/developer-d.... Ryan was being nice when talking about the transition. We put the division through hell for a while (fall of 2008 until spring 2009), but the result was an amazingly scalable centralized version control system. Now with our full, native support for git in VS, on the server (just on the service http://tfs.visualstudio.com http://tfs.visualstudio.com for right now), and joining the community to help build libgit2 (check out the committers page), TFS also supports the best DVCS.