Last week I’ve run across the following tweet:
“It’s getting to the point that if your organization is using #tfs, you are not going to get the best developers to work there. Good luck.” (http://twitter.com/#!/adymitruk/status/81593379204497408)
I can relate to that. I have fought the TFS source control every since it came out in 2005. Notice I’m focusing on the “source control” part of TFS; there are a lot more pieces to this product, but they are irrelevant to this post. From here on, whenever I say “TFS”, I mean “TFS source control”. Before TFS, I had used Visual SourceSafe; compared to that, TFS was pretty good.
I’ve always struggled with weird TFS stuff, but it wasn’t until I got into Mercurial that I finally realized I was spending way too much time with my source control system.
But isn’t TFS better than no source control at all?
Well, yes. I’ve heard of developers who, at this day and age, don’t use *any* source control system. The reasons may vary:
- some say that the company doesn’t want to buy any software
- hmmm… seriously? There are free open source options out there. Oh, no, my company won’t do any open source. Well, *that* sucks.
- others say they work by themselves and therefore don’t need source control (!)
- I totally disagree with that; I have worked by myself in several projects, and have always benefited from having source control (come to think of it, I’ll talk about that in another post…).
So, what’s my beef with source control in TFS?
TFS has been the biggest source of frustration among the developers I worked with in the last couple of years. I’ll list out some of the things that come to mind…
Need for a centralized server
Several times I’ve had a need to work offline. It could be because I was working on a plane, or at anyplace where I couldn’t get a network connection. Sometimes I did have network connection, but it was so slow I’d rather work offline. However, TFS does a poor job at that. When I try to open up a VS solution that’s bound to TFS, Visual Studio takes a long time to realize it can’t connect to the server. After that, I can tell it that I would like to work offline.
But what does that mean? That means I can make lots of changes to my local files, and whenever I’m back online, I can check-in my changes. The part I really dislike here is the fact that I want to check in early and often; write a test, check in, make the test pass, check in, refactor, check in, try out a different implementation, check in, etc. If I don’t have a local repository, that workflow is just not possible.
The need to “check out”
So I’m working remotely, accessing a central server somewhere over HTTPS. I have some source code open in Visual Studio. I hit one key on the keyboard, and there goes anywhere between 5 to 30 seconds (I’ve seen even more) in order for VS to communicate with the server, do whatever it does in this case, and “check out” the file so I can continue editing. Depending on how long that takes and how busy I am, by the time I can edit the file I already forgot what I was going to do to begin with.
“Hey, just get a faster internet connection…”… “get a faster server”… whatever…
My point is, if I want to make changes to files, there is no need to communicate with a server. Such operation has to be as fast as opening the file on any text editor and typing away the changes.
Oh, you want to use “any” text editor…?
Do it through Visual Studio, or else….
Visual Studio several times works as a “big brother”; it keeps watching and controlling everything we do. Because it is such an “institution”, VS is slow coming up. If all I want to do is to fix something real quick in a class, xaml, xml, whatever, I should be able to just open the file in a fast text editor (even Notepad!), make the change, and keep moving with my life.
Well, not so fast. Unless I check out the file, I can’t make changes to it. I then need to open the project in VS and check out the file through the Solution Explorer (this is how 100% of developers should know how to do). Or maybe do it through the Source Control Explorer (I think only about 50% of developers would know how to do it this way). Or maybe just open the Command Prompt and check out the file from the command line (maybe 5% of the developers would know how to do that? Why is it that most developers dislike the command line so much?).
Again, what is the benefit of having to “check out” a file when we want to change it?
Branches… oh, the branches…
Working with branches in TFS isn’t easy. Doing “branch per feature” is a pain. Take the following workflow: I need to work on a new feature, and I’m not entirely sure what the best implementation for it is going to be yet. I have the code off the main trunk from source control sitting on my machine. In order to implement the feature, I may need to create a few files, and change a few other ones (adding a class will automatically require a change to the VS project).
Instead of working directly in the main trunk, I decide to create a branch off of it, because I want to be able to check in early and often while I’m working on the feature, but at the same time I don’t want to mess with the main trunk (and I don’t want changes from others affecting the work I’m currently doing).
Say that this project has 100MB in files. When I create a branch, what happens? I get a new copy of those 100MB dropped into my local file system. Storage is cheap, I know, but if I’m working over a network, I need to wait for all of those files to travel across the wire and make its way to my hard drive.
I then write my tests that encompass the requirements for the new feature I’m working on. I check them in. I decide there are two possible implementations, so I want to create two sub-branches off of the one I’m working on. What happens? Oh yeah, another 100MB for each one of these sub-branches. It’s 300MB of files, when all I need, again, is to add/change a couple of files.
Creating a branch should be simple the act of signaling to the source control system that “from here on, I want you to track changes so I can get a delta afterwards and easily figure out what’s changed”. No need to have copies of every single file for every single branch!
Now, say that while I’m doing this work, another developer has also created his own branch to work on some other feature. Maybe he has written a class or method that I could really benefit from in my branch. How do I get that change of his over into my branch? Well, in TFS, as far as I know, I can’t merge a change from my buddy’s branch into mine; he’d need to merge his changes up to the trunk, and then I’d need to merge the trunk down to my branch. But his changes may have an impact on something that is in the trunk and we aren’t ready to deal with that at the moment, as we both need to finish off the features we’re working on. Hmpf… frustrating.
File Diff
I’ve never been able to use the FileDiff tool that comes with TFS. I can’t make sense out of it. For several years now I’ve been using BeyondCompare, which is a far superior tool for running comparison, understanding changes, and merging.
Odd behavior
I’ve seen some odd behaviors countless times related to developers thinking they’ve checked in everything, but then not all files make into source control, then another developer gets latest, but things don’t work right because the VS projects thinks it needs file X, but file X hasn’t been checked into source control. But then you look at the machine of the developer who made the change, and the file *is* there. We then have to do something like exclude the file from the project, include it again, check it in, and hope that now it is going to work.
I’ve seen weird stuff like that every since the first version of TFS, all the way up to version 2010. It could be a problem of TFS, a problem of VS, a problem of the developers not knowing exactly what the workflow with these tools should be. Regardless, it’s a huge source of friction and frustration.
Summing up
Those are the main things that come to mind when somebody asks me why I’m not a big fan of TFS. Both myself and people who I have worked with have spent a LOT of time dealing with problems somehow related to TFS. Not fun at all.
I’ll write up another post related to what my experiences have been with other systems.
Claudio Lassala's Blog 