Since I work mostly with big corporate clients, I am at the mercy of their company policies. TFS had been released a while ago, but only now it makes its way into mainstream corporate world. Here are some things I have to say about TFS after a couple of months of usage.
Being a big grouch, I will, of course, talk mostly about troubles. But before I do, I must point out that TFS is worlds ahead of SourceSafe. Anything is better than SourceSafe, so by itself it is not a big merit.
In bullet points:
- In other source control systems file is king. In TFS Visual Studio Solution is king. This is not as good as it may sound. Details below.
- If you delete your working copy by hand, getting files back from source control is ridiculously compliacted
- The voodoo-like source control bindings for Visual Studio projects are still their, and they still go wrong at every opportunity.
- Labels are weird
Solution is King
This is not as good as it may sound. One lucky day I wanted to remove a file from the solution. I no longer needed it. To be safe, I first excluded it from the project, to make sure the rest of the program will compile without it. It did. So, I decided to go ahead and waste the file. But hey, it was no longer in the solution, so the user interface would not let me do it. At this moment I could, of course, go to the Source Control Explorer and remove the file manually. I probably should have done just that, but I foolishly attempted to add the file back to the solution, so I can delete it later. The file came back, but now it was marked with a “plus” sign as if I was adding a new file to the source control! Then I made another mistake – I told VIsual Studio to delete it. At this point things went completely out of hand. Visual Studio dutifully deleted the file, but since it thought this is a new file, it did not care to inform TFS about it! See below for info on how ridiculously complicated it is to restore locally deleted files when TFS thinks you have them. Damn!
Another, less dramatic annoyance occurs when you delete the files from the solution outright, without removing them from the project first. When you check in, the “delete” operation is not checked for execution by default! This is because you checking in the solution, and the files you have just deleted are no longer there. You must manually check those pesky boxes, or the files will linger in TFS forever.
Yet another problem occurs when you need to add a random pile of files to your solution. Putting them in a project is not always a good idea – there may be no good Visual Studio project where the files belong, and there is no concept of a “bag of files” project – whatever you create, Visual Studio will try to compile it, create “bin” folder in it, complain that it does not have an entry point, et cetera.
You can, of course, put your files in solution folders, but solution folders don’t really correspond to physical directory structure on disk. You must manually keep the solution folders hierarchy in sync with your physical directories, and this is annoying, to say the least.
Don’t Delete Those Files
If you delete your working copy files by hand without letting TFS know, you are majorly stuck. Whenever you say “get”, TFS will say everything is up to date, because it thinks you must have those files. It does not occur to TFS that someone or something might have deleted these files on disk. TFS does not bother to check and prefers to dwell in its own reality. You can get your files back, but by jumping through some idiotic hoops. Something like “get revision one of the whole thing, which will effectively delete everything and let TFS know it is not there, and then get the latest revision”.
Source Control Bindings Are Still a Nightmare
I don’t know who created Source Control Bindings dialog in Visual Studio, but I have a feeling he was a little bit on the sadistic side. You cannot manually say where your projects are, you just have “bind” and “unbind”. If Visual Studio cannot guess where your project is (or if it was moved, or whatever), you are stuck.
Besides, these bindings are notoriously buggy. They tend to go wrong at every opportunity the see. Right now I have a solution that declares that “there is an inconsistency between project bindings and something else” and checks out every single project in the solution every time I open it in Visual Studio. It does not really do anything to the files, just checks them out, so the next time I open the solution the problem, of course, reappears. I am not sure what’s wrong with it and frankly I don’t have time to investigate it. But there was nothing special with the way this solution was created, and this “feature” is very annoying.
Labels Are Weird
First time I tried to label something in TFS, I found that TFS labels are dynamic, therefore they don’t appear in file history. The explanation for that was something like “you may label a build, then you fix some bugs, and then you want the label to include the changes”. See this blog post from MSDN. This is absurd. Builds are supposed to be immutable. If you fix the bugs and label the result with an old label, you are committing a felony and should be sentenced to some years of hard labor, e.g. routing spam e-mails by hand. Software versions are immutable. Labels are supposed to be static. If you want something dynamic, don’t call it “a label”, or you will confuse everyone. Besides, this dynamic thingie already exists and it is called “a branch” 🙂