Thursday, 15 December 2005

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.

Posted by kevin at 11:43 PM in Net

Responses (1)

Workspaces, Workspaces Everywhere

The first thing to understand about VSTS is the idea of a 'workspace'. The workspace is a client side 'copy' of the data held in source control. Workspaces provide a mapping of source control folders to local directories. Information about workspaces is held in two places, on the client and on the server. On the client the information about the workspace is held in C:\Documents and Settings\[user]\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache\VersionControl.config. The VersionControl.config file maps the name of the workspace to the local directory on disk. It does not hold the mapping between the source control folders and the local directories; that information is held on the server in several tables (notably tbl_Workspace and tbl_workingfolder) in the TfsVersionControl database. No other information is held on the client about the files kept in version control (actually, each project has a .vspscc file associated with it, but this doesn't seem to hold much realm information).

Each user may have multiple workspaces on multiple machines, with each workspace holding different data. This is where things can get tricky. There is no connection between a workspace and a Visual Studio project. What this means is this. Suppose that you have a Visual Studio project open, that project may well be part of a workspace. You could also be using the Source Control Explorer in Visual Studio to be looking at the source code rtepository. The Source Control Explorer also lets you select a differnet workspace (see the image), however if you change workspaces in the Source Control Explorer you get no warning or signal that the workspace you are now browsing does not match the workspace of the project.

Remember that workspaces map Source Control Folders to local directories. This means that if you select a file from within the Source Control Explorer and open it, that file will open within Visual Studio, this may not be the same file as is in your Visual Studio project. You can edit this file and save it, but if you then build your project you will find your changes have not been added.

And the moral is: Be careful with your workspaces, they can lead to lots of misunderstanding!