Things I don’t like about TFS Source Control

I’ve been using TFS at work for about the past 8 months.  Prior to that, I’ve used other source controls such as Seapine’s Surround SCM, Visual Source Safe, and Git.

I’ve used Surround and VSS in production environments, and Git for personal projects.

So far, here are some areas that I think TFS is lacking in source control:

No obvious way to roll-back to a previous version

The other day I stupidly changed a config file from the dev to the test version so that I could hit the test environment from my dev box.  The problem came when I checked the file in, now the dev site was broken because it was pointing to test databases etc.

My first thought was “No problem, I’ll go into source control and roll the file back.”  Only I didn’t find a “Rollback” option.  My next thought was “Ok, I’ll check the file out, get the specific version I want, and then check it back in.”

The problem with that was, when I did a “get specific version” it made my file readonly on the disk.  Then when I made a change, it checked out the latest version. Getting my bad config file again.

My course of action was to view the previous version, do a ctrl+a to select it all, copy it and paste it into the current version.  This worked, but if you do a diff between my last 2 version the file is close to 100% different, and there’s no indication (apart from my comment) that it was “rolled back.”

No way to create a personal or workspace branch

Two days ago I started a mid-size refactoring.  I was about 80% done when I found out I had to make a change for another developer that I was blocking.  I decided to shelve my refactorings, undo the checkout and get the latest so that I could make the necessary change for him. After I did that, I got pulled into some meetings.  Long story short, I didn’t get back to the refactoring for about 24 hours.

In that time, our other developers had added and modified a lot of code.  So when I went and undid my shelved changes, my build was now broken. Because I now had old code that was pointing to non-existent methods.

What I wanted to do was create a personal branch.  In Surround, this is called a “Workspace branch.”  Basically, it’s a branch that nobody else sees. I could have 100 workspace branches if I wanted.  I could do one for each feature or bug.  But in TFS there is no way for me to create a branch that is visible only to me.  And I really don’t want to look at our source control and see each of our 40 or 50 branches underneath dev (2 or 3 per dev.)

If I had been able to create a personal branch, I would have done my refactoring there and then merged my changes back into the mainline.  Which brings me to my next issue:
Merging is a pain in the rear

Right now if I merged from our dev to our test repository I’d probably get 10 files that had “merge conflicts.”  Of those 10, realistically there would be 2 or 3 actual conflicts where the same line was changed multiple times.  The other 7 or 8 would show up as conflicts.

I would open the merge tool to merge them, check the “Show only conflicts” button and there would be no changes to make.  That is all the differences between the two files would have been auto-merged. But for some reason, TFS doesn’t always allow me to auto-merge even when there are no actual conflicts.