TFS as source-control: what do you love? what do you hate?

Question

I've used TFS for about 18 months now and I'm really not excited about it. It seems like the worst of the current versions of SCMs on the market.

I think this thread will help people decide if TFS is for them vs. other source control systems. While TFS does a lot more than that, I think that source control is so critical to software development that any system (or combination thereof) that you pick needs to consider source control first.

What are the good things about TFS vs. other source controls -- what does it do well that no one else does?

What are the things that TFS is bad at that everyone else seems to do just fine?

Answer 1

See this comparison chart between Git, Subversion, Team Foundation Server and Visual SourceSafe.

Answer 2

Hates

1. Doesn't track changes to files unless you've checked them out, so if you edit a file in Notepad++ TFS is unaware that anything changed.
2. It's very easy for someone to check out a fille and lock it so that nobody else can make changes. TFS shouldn't drop this ability, but it certainly should make it much harder to do than it is currently.
3. The methods to undo a commit or two is very unclear, so much so that I'm never quite sure if it worked or not.
4. The way that TFS makes files read only unless you check them out is obnoxious, though it does help me remember to check files out before I save the edits I've made.

Loves

1. I suppose built-in integration with visual studio is nice, if you like that kind of thing (I don't)

Answer 3

Pros

• Fundamentally it's a sound system. Robust and reliable.
• Integrated with work items, reporting, etc.
• The power tools are really good.
• [edit] It is improving, and has taken another good jump forwards with 2010

Cons

• There is one area where the robustness fails miserably: If you apply several changes to a file (add, rename, edit) in "one go" it gets horribly confused. If you don't check in these actions separately, both TFS2005 and TFS2008 crash when you go to merge those changes across branches. [edit: allegedly this is fixed in 2010]

• There is no standalone source control browser. It's integrated into VS, which is really annoying when you want to just work on source control items without needing to run up another copy of VS. Of course, you can give your artist a Team Explorer, but let's ask ourselves if an artist who only ever wants to view the files, check out, check in, and GLV really needs a fully blown complicated VSTS instance running to achieve it? In addition, the integration is so poor that you can't realistically use TFS from the Solution explorer (it simply lies about what you have checked out, and is so unreliable when you apply actions from that window that you soon learn to open the source control window and work in there, which defeats the point of it being integrated in the first place) [edit: The file explorer extension is excellent - close to a standalone browser - and is simple and easy to use. The main drawback of it is lack of proper integration with file commands - to rename or delete files you must remember to use the TFS submenu, or you will rename/delete locally and this screws up source control completely as TFS knows nothing of the changes you have made. This unfortunately means that only 'advanced' TFS users can be trusted to use it. So, essentially, it's still a case of "no stand alone browser" for most users]

• The user interface sucks. Sure, it works, but there is so much that could be done to make it efficient, pleasant, and more foolproof to use. e.g. When you click "check in" it ticks all remaining un-checked-in items so that if you accidentally click Check in again in future, it checks in a load of stuff you didn't want to. And after this, it would be so easy to supply an "undo last checkin" option to quickly roll it back - but there isn't one. [Edit: The UI is improved, but these specific problems are still present in VS2010, although it does now have a check-in confirmation dialog that reduces the risk of accidental checkins]

• Workspaces. In most cases, every team member has to have essentially the same workspace mapping, slaved off a local root folder. We need 7 mappings defined, which takes about 5 minutes to set up. There is no way to push the workspace definition from the server. There is no [edit]easy[/edit] way to duplicate a workspace so you can use an existing one (or another users one) as a starting point. No, you have to manually re-enter all the bindings over and over and over and over. If you change your active workspace in the source control explorer, it doesn't get synced to your pending changes window, so you spend 15 minutes wondering why the file you merged from your other branch just isn't listed.

• It has changesets, but you can't bundle items into separate changesets in your pending checkins list as you can in Perforce, you can only associate them with a changeset by actually checking them in. You can really only work on one changeset at a time, or you have to separate the files out manually in your pending list as you go to check in.

• The merge tools are terrible. As in: they simply don't work, and unnecessarily introduce bugs into your code if you rely on the automatic merge. These tools are just as bad as they were when I first used SourceSafe in 1994. So the first thing you have to do after buying a very costly VSTS licence is replace the merge tools with something that actually works. And that means that every time you get a merge conflict, you must select each file. Choose to resolve the conflict and ok. Choose to use your 3rd party merge tool and ok. Then merge. Then save. Then choose to accept your merged changes. (You should be able to choose "automatic merge" and have it simply use the third party merge tool that actually works without hitting you with a barrage of pointless and annoying dialogs that always default to the wrong option) [Edit: InVS2010 the merge tools are still awful. But the front-end UI is much improved (merging a conflict now takes a single click rather than 4 or 5 clicks - a massive improvement when you have to merge many files]

• It doesn't sync between running instances of VS. So if you check in a file in one VS, another one will still list that file in your pending checkins. (it's clearly easy to sync it because any changes made by the power tools windows-explorer extension are reflected in VS instantly).

• Branching is the standard way of working these days. So you'd expect the branch/merge tools to make this quick and easy. But no. (This looks as though it may have been fixed with VSTS2010)

• If you GLV (get latest version of) a solution, and some of the projects in it have been changed, VS repeatedly asks if you wish to reload each changed project. It is about 10x faster to close your solution, then GLV, then open the solution again than to GLV with it open. If I'm GLV'ing then of course I want to reload the projects! When I buy my food at the supermarket they don't ask me for every item "do you wish to take this item home with you?". [Edit: Still broken in VS2010]

• [edit] If two team members add a new project to a solution, then when the second person goes to check in, they must (obviously) resolve a merge conflict. However, TFS treats the .sln as a text file, and corrupts it (it adds the two project entries but the project count is effectively only incremented once).

• [edit] I don't do any source control operations from within the Solution Explorer window, as it has been rather unreliable ever since "integration" first came along. Even in 2008 it usually has random "checked out" icons on files that are not checked out, and recursive operations sometimes do weird things. Almost every source control 'glitch' we have is a result of someone starting an operation from the Solution Explorer. Luckily, I prefer to work in a Source Control window anyway.

• [edit] Where to start with the Source Control Bindings window? VS could say "Your Source Control settings have been corrupted again for no obvious reason. I never could get the hang of Thursdays. Shall I fix this for you? [YES]", but instead, it shows a complicated, confusing dialog full of information that makes no sense to anybody, resulting in a UI so scary that it makes junior programmers soil themselves. The trick is to ignore the whole window, hide behind your desk and click the "fix it" button, and it fixes it.

As you can see, most of the above are just trivial UI gripes. There is such a lot that could be improved about the UI. But the actual underlying product is good. I prefer TFS to pretty much every other SCM I've used over the last 28 years.

I wouldn't even mind the poor UI so much, except that it is one of the core UIs developers have to use on an hour-by hour basis, and they have to pay such a lot to get it. If the subscription money from a single developer was invested on improving the UI it would make a massive difference to the usability of TFS! It's painful to think that TFS is merely good or ok when it could so easily be excellent with a bit of nice UI.

Answer 4

I think that TFS is the single best ALM product on the market today. Looking at it from only a source control platform is slanted. I have used many products in my career to date: VSS, SVN, Git, StarTeam, CC/Harvest, and ClearCase - apart from TFS. Personally, I cringe at the thought of going back to anything other than TFS.

TFS is an extremely powerful platform. My biggest problem with it is often related to people not knowing how to use it or using it incorrectly. It is not meant to be an application that "just works". Sure, you can use it for basic source control without learning much about it - but if that is all you use it for, then you really are better off using one of the less robust tools out there. In reality, what TFS does not give you is the way to interpret features how you want to. It is specifically built from the ground up to support process and not just be a repository.

Answer 5

Con: Checkout model. Many applications do not deal well with files that are marked as read-only then change to writable (Word 2007, Notepad). So you open a file, edit the file, try to save then you're told that you can't save because it's read-only. Great, now you have to Save As..., delete the original and renamed the new one to the old name. If there's an upside to having local files be read-only I don't see it. I really prefer Subversion's approach to this.

The one upside to making files read-only is that it reminds you to check them out. However that's really just a symptom of the check-out model.

Answer 6

I am a member of the Team Foundation Server team at Microsoft. There are a lot of very valid issues raised here. Some of them are addressed in the 2010 release. Others remain as issues, but we do recognize them and are working to improve the developer experience with the next release. Discussions like this are great for helping us make sure we're solving the right problems.

Here is some info on issues that are at least partially addressed today in the 2010 version:

Stand alone client

For non-developer customers that want to use the product outside of VS, they can use the Windows Shell extension powertool.

If you have users (developers or not) that need to access TFS from non-Window machines, they can use Team Explorer Everywhere. This is supported on platforms including Mac & Linux.

Copy workspace

There are two ways to copy a workspace today. The 1st is by using the workspace template command at the cmd line. Ex.

Tf /workspace /new /template[workspace name/owner to copy from]

Alternatively, you can open a workspace in the UI, select all of the mappings, copy them, & then paste them into a file/email. Someone else can than paste those same mappings into their workspace.

It would definetly be great if you could simply specify a default workspace that clients automatically pick up, but we don't have this today.

Merging robustness

The scenario described where you do an add, rename, add & then have problems when you merge has been addressed in TFS 2010.

Branch/Merge as a 1st class experience

In TFS 2010, branches are now 1st class objects in TFS. You can visualize your branches & even track changes as they move through the branch. Branching is also now a fast server based operation.

Get Latest Version of multiple projects

You can do this today by choosing the TFS instance node in source control explorer & then selecting get latest. This is the equivalent of the root folder ($).

File locking

By default TFS never locks files when users checks them out. This is the way we use TFS at Microsoft & how we see the majority of our customers using TFS. It is possible to enable users to explicitly lock files. Some customers find this desirable, but it is not the default path experience.

Answer 7

The lack of true rollback support and the inability to rename a TFS Project are my two main pet peeves with TFS. Other than that, I've been very happy with it for 2-3 years.

The fact that certain applications do not support in-edit changes from read-only to writable (forcing you to reopen the file in question) is annoying but is really a problem with those specific applications. The fact that a file is read-only while not checked out has certain uses, one of which being that it reminds you to check out the file. It does occasionally, however, lead to confusion when trying to get specific revisions of files. Writable files are not re-downloaded unless you enable a flag, because they're considered local edits.

Answer 8

Con: Timestamps. There's no way to set TFS to use the remote last-modified timestamp as the local last-modified timestamp. The local file's timestamp only tells me when I got the file. If I get a file that's 2 years old, there's no way to know that based on the local timestamp.

Other source controls that I have used have this ability.

Answer 9

Cons:

• workspace version: You can't identify the version of a workspace without doing a recursive search.
• terrible offline experience. attrib -r + tfpt online shouldn't be the way to work offline. Give me something like git that allows me to track status, undo and make changes. I'm even fine if it only stores the difference between the workspace version and current.
• Merging robustness: a changed file on the server + a local edit on different lines is not a conflict. a writeable file should not be an automatic conflict. The automerge button should NOT exist, because it should never be a scenario.
• Workspaces: the idea of being able to rearrange the source structure is just odd, and causes issues. the requirement of having both branches mapped in order to merge is odd. The requirement of having to do an operation multiple times, because my workspace mapping doesn't have a true root folder is wrong.
• Full reliance on remote server: There are some nice things about having all these things stored on the server, but really, you could store information locally and then upload it when needed. Keep pending changes, workspace mappings, basic undo history locally, etc.

Pros

• Shelvesets: I love these, and wish support for them was brought to the local disk as well (think git stash)
• Source control view in VS: It's pretty cool to be able to view the entire repository without downloading it. There are some usability issues, but the overall idea is cool.
• Workspaces: yep, both places. While re-arranging a repo is odd, the ability to only download what you need is pretty awesome. I often wish I could choose a root folder and then check box the paths I need, but oh well.

Answer 10

Dislikes: -Using the history to figure out what has been done is cumbersome to say the least. You have to click on every single history entry to see what files were changed, and then you need to go through a context menu to get a diff. -Working while disconnected from the network is a big no-no. Ever heard of working on an airplane? -No Windows Explorer integration for when you work with files outside of VS (think TortoiseSVN). -Process methodologists (configuration managers) love to not allow shared check-outs. This is absolutely horrible for example for config files that you need to modify for testing. -SC gets confused with complex move/delete operations. -SC does not recognize when a checked out file has not changed. For example, service reference updates check out all related files and often regenerate the exact same content. These files should implicitly be removed from check-ins because they just add noise when you look at your changeset later.

Likes: -Shelving.

Anybody guessed which is my favorite SCM system? SVN + TortoiseSVN + VisualSVN :-)

Answer 11

Search functionality is not implemented in TFS 2010 ? VSS we have search in file; TFS 2008 we have search file ...

Answer 12

Con: If you want to move multiple files to a subfolder of the existing location, you have to do that one at a time. Wow, that's horrible.