I'd prefer to post a positive, happy, or ideally emotion-agnostic technical post, but today Microsoft Visual Studio Team Foundation Server (TFS)'s source control pissed me off one too many times. I could go on for pages, but this list represents the top eight reasons why you should never pick Team Foundation Server for source control (in decreasing order of annoyance).
1. Can't see changes on get latest
If you like to publically humiliate co-workers when they violate coding standards, or even if you just want to keep an eye on what they're doing, then TFS is absolutely not for you. I'm completely spoiled by Tortoise SVN which allows you to
- Get latest
- See which files have changed; and
- Quickly view the diff
I suppose I should be happy TFS at least allows #1.
2. TFS drops Solution Items
Solution Items are files and folders that exist outside of projects, but within solutions. For instance my current project has an etc directory that contains database scripts and such. First of all it would be nice if Visual Studio automatically recognized new items in the etc directory. Ironically you have to "add existing item" even though it already exists. Fine, whatever. But more importantly it would be nice if Visual Studio didn't periodically delete said files from the solution. As convenient of a feature as that may sound, it has caused numerous problems. A "Blame" has determined that nearly every person on the project has activated this feature leading me to believe it is truly a bug. Brilliant.
3. Checked In Files Are Marked Read-only
Suppose you have a file you want to open outside of Visual Studio (gasp). With TFS if you don't already have Visual Studio open you have to start the IDE in order to check the file out to remove the read only bit. So ten minutes later you're ready to go. At least TFS does allow multiple check-out.
4. TFS server name in project file
TFS embeds the server name in every single one of your project files. The beauty of this approach becomes evident when one team member uses an IP address, while another uses the domain name or computer name. You end up fighting over the project files and automatically checking them out when all you want to do is view them.
5. Can't Access Source Control Outside of Visual Studio
Want to check in or get latest without opening Visual Studio? Yea, you can't. Hope you don't have any java (non-Microsoft) code on your project.
6. Reconciling, Painfully Slow
TFS actually does a decent job of auto merging conflicting files. And when it can't auto-merge conflicting files you can view each file side by side and click which change you want to keep. But the process is painful and slow. For instance if you forget to get latest before check in and there are conflicts you can resolve them, but your check in will always fail. Get latest seems to take much longer when there are conflicts. Auto merge is really slow. If there are un-reconcilable conflicts hitting the "resolve" button takes forever and must be done for each and every conflict. It's like it downloads the entire history of the file. And that wait is mandatory even if you simply want to discard either your or the server's changes.
7. *.vsmdi files
This is just a frustrating known bug where if you use TFS for unit testing (Team Foundation Server Test System) and TFS for source control, Visual Studio will either take this .vsmdi file which is essential file for unit testing and either duplicate it or corrupt it. There's a lot of ink spilled on this vsmdi bug and there are some workarounds, but it's a pain.
8. Moving a folder opens all files in the folder
This was the last straw and the impetus for writing this post. Today I wanted to move a "solution item" into a project. I opened the Source control Explorer (which is impossible to find in the first place) and right clicked, selected move, entered my destination, and TFS in its wisdom opened every file in the folder nearly bringing my machine to its knees. There are hundreds of small annoyances like this every day with TFS.
TFS actually has some nice features that I like over SVN. Like the merge tool is pretty good, and being able to see all people who are currently working on a file is nice. But overall the cons heavily outweigh the pros. And if it's any indication how bad TFS is for source control (or how much developers hate it) Codeplex has even implemented a SVN to TFS bridge on their server.
It's ridiculous to me that Microsoft uses this tool internally and sells it and people buy it! I must be missing something. If so please post comments to this post. Because the entire thing boggles my mind.
Many of the operations still require that a GUI dialog presents (tf checkin) , but a simple get-checkout-edit-checkin cycle does not require a Visual Studio instance, and can be called from most editors that can shell out commands.
Unfortunately the above requires VS be installed, which is an unfortunate waste of time and resources for someone who uses VS solely as a TFS interface.
Thank you for the info. I took a look and the TFS Power Tools soften some of my criticism. It's certainly no TortoiseSVN, but I guess it makes TFS usable for a project with non-Microsoft files in it.
I had too many case where I could not check-in, clean-up would not work, I would need to edit the SVN files to fix it, or pull everything from scratch. Moving folders was a pain. Did not integrate with VS so adding new files or renaming them was a pain.
Working on various types of projects in VS caused issues also, seems every month we found a file type which needed to be excluded.
I also tried the various addins and they helped but I still rather use VSS.
At least VSS always worked for me, but agreed VSS is dated and lacks features.
TortoiseSVN has improved A LOT just in the last year. You might want to take a second look. Exclusive checkout in VSS is a deal breaker for me.
I agree exclusive check out is a terrible solution to have unless your team is so small you never have file collisions.