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.
