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.
We’ve had similar things occur. One of my biggest gripes with TFS is the limit of 256 characters they put on a path, which messes with our branching all the time.
Did TFS not submit the five files in the first place, or does it think it submitted them but lost the changes? In other words, do the five non-updated files appear in your changeset record? If so, if you diff those versions against the previous versions, do your changes appear?
If the files didn’t make it into your changelist, then maybe you somehow managed to edit the files without first checking them out? (Yeah, I know, I’m probably insulting you by asking trivial questions, but still . . .)
If the files are in the changeset record but don’t contain the changes that you had locally, then yeah, that seems very scary.
@punkcoder – the TFS path limit is actually a Windows limit. There’s no point in having a path in TFS that you can’t actually sync onto your local disk.
i remember running into various little quirks like that when i had to use TFS 2005 at a client a while back… now we just use a subversion repository with the Visual SVN plugin for visual studio. Never causes problems and works like a charm :p
@Eric The files were checked out properly. I guess that TFS submitted the files but lost the changes. There is also no way I get the old files back on my machine.
I’m not the only one who experienced this issue. As you mentioned, it scares me.
Heh what version of TFS was this? We had similar problems all the time with 2005. Having to recreate development branches from older main branches, which kind of defeats the purpose of source control. We have only recently upgraded to 2008 and haven’t noticed any such problems yet.
Also, you can’t revert a changeset in TFS, and unshelving shelvesets simply overwites files changed by someone else rather than merging them. It really is just a slightly less stable version of VSS with a few ideas brokenly borrowed from distributed systems like the branching and merging, with a pretty weak issue tracking system tacked on.
Mercurial FTW!
@Kurt We are using TFS 2008.
I’ve had the same issues on 2k5 many times. My solution was a small script checking out the whole solution and undoing the checkout with the powertoys
tf checkout /recursive *
tfpt uu
These days I’d simply use svnbridge
@Sebastien: SvnBridge: why didn’t I think of that? Thx for the tip.
The October version of TFS Power Tools includes shell integration if that’s the part of SVN bridge you are looking for.
@jan, Were the missing files identified in the changeset created by the checkin? Here’s the deal, man. If I can verify this behavior, I have direct access to the guys who write the SCC system for TFS. They aren’t “Microsoft”, but are in fact people who are darn good developers who care about the product they make. If I can see this behavior and figure out some of the workflow steps to repro it, I can being it to them. They’ll care.
@David It happens about once a week on rather unpredictable terms. It seems to happen more with larges changesets. As soon as this turns up again, I’ll let you know about the changeset. Are there any log files I have to watch out for. Maybe they can help as well. Thx for the help. I really appreciate it.
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.