TFS Tidbits–The Atomic Check-In

In a previous article, I talked about how TFS treats check-ins as atomic transactions. In a nutshell, when the check-in is initiated, Visual Studio will provide TFS with some basic information about the check-in. like the number of files and the work item(s) associated with it. When the transmission is complete, all the elements will be associated with a Changeset number; otherwise, a changeset will not be created and any code trying to be checked in will not be committed to the source tree.

Personally, I had been curious what the user experience would be like if the check-in took longer than expected. Well, while working on a project for my team and checking my part of the code into TFS, the checked took longer than expected and I received the following error message:

You might be thinking “big deal”. This isn’t all that exciting. But in a past life, I’ve been bitten by networks hanging for whatever reason during a code check-in and I never quite knew exactly what changes made it into the repository and which ones didn’t. So I ended up doing the check-in again and got prompted that  a number of files are the same and it was the last two files that hadn’t made it so those where checked in finally.

By receiving the error message above, I knew immediately that all the files I was trying to check-in weren’t committed to the repository, so all I had to do was click the Check-In button again. Obviously my network connection the server was better the second time around and the code made it in as expected and a new Changeset was created.

We’ll now return you to your regularly scheduled worked which was previously in progress.

Share and enjoy!

Excelsior!