How TFS Lost my Trust
This morning, I spent the first 30 minutes of my day figuring out why the CI build failed after I checked in some changes to the code. No big deal, right? I just messed up. Turns out that I didn’t screw up the code but TFS did.
Before committing the code to the source repository, I merged with the latest version on the trunk and ran all the unit tests. Everything was fine and dandy. After I checked in the code, TFS decided in all its wisdom to not update 5 source files, which were randomly picked of course. I didn’t get any errors when I committed the code, so I was completely unaware of any problems whatsoever.
When I noticed that the CI build had failed, I naturally tried to figure out what was going on. From the build log I noticed some compiler errors about classes that couldn’t be found. I checked and double-checked whether I forgot to commit them, but I didn’t.
This is something that happens about once or more times a week. To fix this again, a colleague has to update its local copy of the source code and determine which files are skipped by TFS. Then I have to ‘touch’ those files on my machine and check them back in. At this point, valuable time of two persons is wasted.
I strongly believe that a source control system is the backbone of any proficient and productive development team. If you can’t rely on a stable source control system, then what’s the point? I consider TFS to be seriously broken. The upside of this sad story is that I’ve really come to appreciate a stable source control system like Subversion and the people who spent their free time in order to accomplish that.
There, I’ve got it out of my system. I can breathe normal again.
What’s really important is what made it in the changeset, what didn’t and why.
So, when you see this:
1. Go to a clean workspace.
2. Get the changeset number for the changeset that screwed you.
3. Do a tf get # where changeset number is the #
4. Were the files in question in the changeset?
Then, look at history on the files in question. Hisory in TFS only shows Changesets, not labels (fixed in Rosario). Does the changeset appear on the file in question?
Here’s what we are looking for: If the file in question is NOT in the changeset, go back to your coding workspace.
1. Is the file checked out?
2. Does the file on your local workspace have in it the change that you expected to see in SCC?
3. Is the file read-only or writeable on the local file system?
Basically, I am looking to ensure that the change was actually committed.
There’s a service pack for Team Explorer – KB945140. I think this is installed automatically as part of SP1 for VS 2008. That might help.