Almost, but not Entirely, Unlike Version Control

Version control in VSTS is almost, but not entirely, unlike any other version control system I've ever used. I'm a long time user of other version control systems, CVS for several years and more recently (last couple of years) Subversion. I wasn't a huge fan of CVS, being mainly a Java developer I need support for directories as Java packages use an on-disk directory structure and CVS's support for directories sucked. However, I do like Subversion, I have several repositories that I administer, mostly source code but with some other work related bits in. Both Subversion and CVS are desgined to work in disconnected. That means that as a developer I can check out code from the repository, work on it when I need to, and check it back in when I'm done. The primary advantage of this is that I can work away from the network, on a plane for example, or on a customer site where I typically don't have network access.

In both CVS and Subversion the server takes no account of the clients code, that is no locks are held in the server regarding the client's checked out files. CVS does use locks internally to manage it's file system, but these are like database locks, they are there to stop data corruption. Subversion has introduced locking in 1.2 to support reserved checkouts, but this is the exception rather than the rule. In CVS/Subversion once the user has checked out files she can do with them what she wants, including deleting the files from disk if necessary. The CVS/Subversion servers are blisfully unaware that the checked out files even exist. Both CVS and Subversion maintain hidden directories on the users local disk, and it uses the data in these directories to decide what to do when the user access the repository. So if the user has edited a file on disk then the file can be compared against data held in the .svn directory before the file is uploaded to the server. This mechanism is known as copy-modify-merge

The new version control system is also a copy-modify-merge system, sort-of. VSTS eseentially maintains no data about files that are in version control on the local disk apart from a couple of things. There is data about the workspaces that a given user has, and each project file (csproj etc.) holds information about the source control mechanism in use and each solution file knows which projects are in version control and which server they are associated with. Given this paucity of information how does the version control system "know" that you have changed files? CVS/Subversion "know" because they can check against the data they store on the local disk, VSTS can't do this! VSTS tracks all version control changes through the database.

When you check a project into VSTS the files get marked locally as read-only. This is a warning to you that the files are in source control. If you open a file in Visual Studio and edit it, this sends a request to the server. The server then checks that it is OK to check out the file (another user may have locked it), then in the database marks the file as having 'Pending Changes' and sends the latest copy of the file to the client. The client application then removes the read-only flag. If the user tries to check the file back into source control the client sends a request to the server that then checks to see if the file has changed, if so, the check in happens, if not, the user gets a message saying that nothing needs to be checked in, and the file gets put back to read-only again.

This is a complete pain in the neck, the primary issue being that it is difficult to work off-line.

If you are disconnected from your the TFS and open a Visual Studio project that is under source code control Visual Studio tries to communicate with the source control server. When it finds it cannot do this you will get a dialog telling you that "The solution appears to be under source control but its binding information cannot be found. ..." then another dialog asking whether you want to temporarily work uncontrolled or to remove the project's source control bindings. If you choose the latter then the source control information is removed from the proj file and, so far as Visual Studio is concerned, the project is not under source control. If you choose the first option (temporarily work uncontrolled), then the bindings remain but the files are left as read-only. As a user you can, of-course, make the files read-write and then edit the files. The problem now is, if you edit the file the server doesn't know! This means that you are going to have to track your own changes; then remember to check out the files you have edited; then check those files back in.