Get latest before checkout

One difference between Visual Source Safe (VSS) and the version control in Team Foundation Server (TFS) is that VSS performed a get latest operation before checking out a file but TFS does not offer this functionality. This caused an issue for a few of my colleagues and until now, I didn't know of a way around this problem. For those that are interested, Greg found an article here that describes how to alter this behavior and you can download the file from CodePlex. However, the add in doesn't do it for me because IMHO, you should NOT perform a get latest before you checkout and file and here is why.

Microsoft have lulled us into a bad head space when it comes to source control. No source control system should manage state, but VSS and TFS both manage state on the server. This just causes no end of problems and doesn't represent what source control is all about. The topography of source control should be a hub & spoke situation - once a client performs a get latest on the server, the server does whatever it needs to to provide the information to the client and then severs the connection. The server should not maintain that Joe Bloggs just checked out file x because it makes absolutely no difference. What if that person kept file x checked out forever? Would it matter? No, not at all. What matters is what goes into the repository, not what comes out of it. In fact, the whole concept of check out is flawed. It's not that you are checking out the file, it more that you want to make changes to a file. In TFS land, check out means "update the server with a record saying that I'm maybe going to edit a file" and undo checkout removes the record. What's the point of maintaining that you might do something? Ultimately, once you have the latest source on your machine, you shouldn't need to contact the repository again until you want to commit the files.

Take this scenario:

• there are two developers, Bill and Ben
  
• Bill makes changes to the customer code file
• Ben makes changes to the customer code file
• Bill checks in his changes
• Ben checks in his changes

What happens here? Whose changes are accepted? What actually happens is the server performs a merge on every check in and if the code can be merged without conflicts, the changes are merged and accepted into the repository. So in this case, as long as Bill and Ben's changes merge successfully, there will be no issues and their changes will be merged together.

However, there is a fundamental step missing from this scenario which causes the most headaches. Before you check in, you should always perform a get latest. If you don't, the version control system will attempt to merge your changes together but it's a horrible position to be in to be caught short when your trying to update the repository. A much better approach is to perform a get latest on the entire solution before you check in. This way, any files that have changed are brought to your machine locally and you can merge/diff/rebuild the project and run your tests before checking in.

Lastly, and my main point about why get latest is bad before checkout, imagine this scenario:

• There are two developers Bill and Ben
• Ben makes changes to the customer file and these changes require changes to several other files file to complete the change successfully
• Bill wants to edit the customer file and he does a get latest before he starts. When he tries to compile, it will fail because he did not get the related files that Ben changed, only the customer file. Therefore, Bill also has to get all the other necessary files to make the solution compile. He doesn't know which files these are and so ends up having to get latest on the entire project
  

This scenario is bad because you haven't completed doing what coding changes you were working on and yet you've had to mix changes from other people. Basically, you should not perform a get latest on a individual file otherwise you are only getting a partial get latest when it comes to building the entire solution. Also, before performing a get latest, you should finish your own changes first and ensure it compiles and passes all the tests before introducing changes from other member of the team through a get latest. Remember, get latest cannot be undone, so if you have your IDE perform a get latest before you check out a file and you end up in the above situation, you could spend a lot of time putting things back together before you are ready to.

In general, when you are working with source control, you should follow this procedure:

• Make changes to the source
• Build the solution and run your tests
• Perform a get latest on the entire solution
• Build the solution and run your tests
• If it builds and all the tests pass, check in

Get latest on an individual file is fine if you understand the repercussions of what you are doing, but having your IDE automatically get the latest copy of a file before you check out defeats the purpose of having a source control system there at all. Assuming it were possible, why not just have all team members working from a central file resource so they alway have the latest files? Can you imagine what this would be like? This is exactly what is recreated if you get the latest version of a file before you make changes to it.

Using Team Foundation Server Power Tools

There are lots of useful tools in the Microsoft Team Foundation Server Powertools, most of which should have been included in the the Visual Studio IDE. The tools that I find most useful are:

Annotate
The annotate command downloads all versions of the specified files and shows information about when and who changed each line in the file. To access the annotate command, right-click on the file you want to annotate in the solution explorer (or Source Control explorer) and select annotate. The annotate command is also accessible from the File, Source Control menu.

When working on a multiuser project, this is a very useful interrogation tool. Along the left hand side of the annotate window, is also displays a hyperlink to the change set which included the code change you are looking for. You can click on this hyperlink to see the other files that were included in the change set. The hyperlink also includes a tooltip which shows the check in comment - very useful. and treediff

Treediff



The treediff command displays a visual representation of the differences between files in two server folders, in a server folder and a local folder, or in two local folders. Treediff can be used from both the command line and inside Visual Studio. The command line version creates the same GUI representation as presented by Visual Studio. The command version is accessed using TFPT Treediff.
Treediff has 4 filtering options:

• Items that exist exclusively on the server tree
• Items that exist exclusively on the local tree
• Items that exist in both trees that have different contents
• Items that exist in both trees that have the same contents

Each of these options can be selected individually or combined to produce a comprehensive report on the differences between what you have on your local machine workspace vs what is on the server. From the output, you can compare, view, get latest version, add missing files and delete each of the files as necessary which makes this tools a good way of keeping your file system tidy. It can be particularly useful if you want to prune all the files in your local workspace that don't exist on the server.
Take care with the delete option - it changes between "Delete" and "Delete Local Files" depending on your selection. Fortunately, all the changes you make inside the treediff become part of your pending changes list and you have to check in for the changes to be accepted.

Process Template Editor



Team Foundation Server Power Tool installs Microsoft Visual Studio Team System Process Editor, which is a process template editor for editing Team Foundation Server process templates inside the Visual Studio IDE. The installation media includes separate documentation for the Microsoft Visual Studio Team System Process Editor, which includes a User Guide and a Readme file that includes known issues.

Although this tools is still pretty raw, it can save you a lot of XML editing and makes editing a process template a lot easier.


Undo Unchanged:
The undo unchanged command undoes redundant pending changes. This means that is the state of an item with a pending changes is the same as on the server, then the change is undone. This command is very useful if you have Visual Studio setup to check out files automatically. It helps prevent files being check in the have had no changes made to them and have been checked out unnecessarily. During the undo unchanged operation, any files that have not been checked out but are not up to date on your local workspace are retrieved from the server. This feature can be suppressed using the /noget command line options.

I'd like to see the undo unchanged command being run before every check in to freshen the pending changes and integrate your changes with the server before you start your check in procedure. This coupled with the tfpt review command which show a window of all your pending changes and allows you to go through each change doing a diff against the sever. As you diff each file, it is ticked on the review window which is a nice way of working though and validating each of your changes and helping you track where you are up to.

For a list of other command available on the team foundation server power tools, type TFPT at the command prompt. Note: depending on your path setup, you may need to change to the team foundation server power tools directory to get access to the TFPT command. I've added the default installation directory for this tools to my environmental path statement which makes more useful as it can be accessed more easily. The default installation directory is C:\Program Files\Microsoft Team Foundation Server Power Tools.

Download the Microsoft Team Foundation Server Power Tools