Microsoft® VSTS (Visual Studio Team System) is a really cool idea.  It combines a lot of common concerns for a lot of developers, offering a one-stop shopping experience that's really appealing. 

It's comforting for most people to be able to manage their version control from the same interface in which they are making the changes necessitating the control of versions.

It's useful to be able to see what other members of one's team are up to, and tie issues to actual change sets in code (and be able to report on it all).

It's empowering to be able to apply custom check-in constraints to force comments on code changes (or integrate one's own time tracking, as we have done where I work).

But I'm not writing to discuss all these points.  The points above are well-documented by Microsoft® and require no further lobbying from the likes of me.  I like VSTS, to be sure, but there are some shortcomings, in my opinion.

Last Friday was going to be a big day for my team.  We were about to implement a code branching strategy for our version control system, which was needed, but had been badly applied in the past and which was the cause of a certain amount of angst among the senior development staff.  I was in charge of implementing the changes, which included adding a new layer to our folder hierarchy and moving all active development into that folder.  In my experience with version control systems, it is usually an exceptionally bad idea to change the folder structure while there are pending changes in the system, so I sent a preparatory email to the affected developers (a relatively small, manageable number of people) to please resolve their pending changes before I began the update.More...