I am new in configuration of TFS.
Currently our project is 50% done but we found that we have very bad code. We consider the need for static code analysis like Resharper or another product like StyleCop, CodeAnalysis and FxCop.
We want configure the TFS to reject a checkin when that check in contains code that triggers code analysis warnings.
But for the previous code we want to suppress the existing warning to prevent the code from becoming worse than it already is.
As Ivan mentions, your root cause it not in the lack of analysis tools, but probably in the level of quality and rigor agreed (or currently being enforeced between team members) between the development team and their project's sponsor. It may be that the pressure on the team is too high, causing important review actions to be skipped, or that the team (or the sponsor!) doesn't have the same desire to quality as you or the sponsor. Or that the team doesn't have the right level of knowledge to prevent these issues from happening.
The best way out of this is to fix as much as you can in a short period of time.
Warning: I've experienced with a number of teams the effect of turning on too many rules all at once. Generally, there is a reluctance for people to concede that their work hasn't been up to par and turning on rules that do not directly cause bug ("The identifier is cased incorrectly" for example) can cause frustration that can severely hamper your momentum. Carefully selecting which rules need to be solved now and which can wait for later worked much better in my experience. Once the team has developed a way to solve these kinds of problem, you can easily apply more.
Turning on Tools like configuring Code Analysis for your solution or using the Solution Wide Analysis feature of Resharper, can help you spot issues, but it won't solve them or prevent similar issues from popping up in the future unless your team stops creating them.
Tip: Note that you can turn on Resharper during your build as well using the Resharper CLI features.
StyleCop I would not enforce on this team (just yet) if the code itself is bad enough to trigger massive warnings that may hold bugs and issues. Fix these problems first, make the code it pretty later. Your priorities are now to remove any possible bugs.
CodeAnalysis and FxCop are the same things, so you won't need to turn on both. A tool like Resharper can help your developers to quickly remove a lot of the issues by using the magic-key ALT+ENTER.
If you want to create a clean baseline you can run code analysis once, then select all warnings that are generated and then select Suppress in global suppression file. This will work for Code Analysis issues, but won't suppress any Compiler Warnings, there is no easy way to quickly suppress all current compiler warnings.
Tip: It sometimes helps to temporarily rename any existing globalsupressions.cs files, so that this "baseline" is stored separately. You then know which warnings you'll have to fix at a later point in time.
Tip: When a developer suppresses a warning, have them add a Justification="Reason for suppression" to the suppression that is generated, that way you can distinguish between carefully considered suppression and temporary ones.
Depending on whether you already have a build server your next step is to install Team Build and once you have a build server you'll need to setup a Build Definition. This blog post covers most of the steps.
In the build definition set the trigger to "Gated Checkin" and on the Process tab make sure you set Code Analysis to "Always". If you want to fail your build based on Code Analysis errors, you need to create a custom ruleset and configure that for your solution.
To have compiler errors fail the build you can also enable the "Treat Warnings as Errors
Once you have enabled your gated check-in build all developers changes will be prompted to wait for their build to finish. You can turn on alerts (using Web access) or use the Build Notification Tool to get notified when the changes were successfully submitted.
Tip: Instead of turning on all rules at once (or switching them all to cause an ERROR during builds) you can also opt to turn on rules a couple at a time and fix them. Turning on rules by category gives you a nice opportunity to teach people the importance of the rules being turned on and possible solutions for fixing them.
A far more advanced solution would be to install and configure SonarQube alongside your Team Build environment. The ALM Rangers and Sonar have recently worked together to create installation guidance and a number of extensions to enable Team Build and SonarQube integration. You can find the installation guide here.
I'm finding that a number of my changes are being 'lost' when our contractor performs a check-in.
The general process is as follows:
I perform some bug analysis and implement a fix.
I then check-in my code.
The contractor performs a check-out/check-in at a later date.
The changes from the previous changeset (my changes) are lost.
In my view, this is pretty unacceptable, particularly when I'm dealing with application-breaking regressions introduced since the last build.
This has happened at least twice now, and the only thing I can think of is that the contractor is failing to ensure that he has the latest changeset at check-out. Our repo does not allow multiple check-out, and forces get latest on checkout, which makes things so weird (seeing as we both should be working with Server workspaces).
Could there be any other cause of this problem? I don't want to take my concerns to my line manager without being sure I've covered all bases.
Get Latest item on check out is set in the client and not in the repo, which means that your contractor may still be able to checkout the wrong version. They should get merge conflicts upon doing so, but that depends on where they edit (and how they manage such conflicts).
I've seen TFS lose changes this way. I have yesterday gone to a client site, made changes, checked in, today come back to my office, got the changes (assuming it will merge with my local changes like it usually does), gone to check in just now and I can see in the diff that it's wiped out the client-site changes (obviously ignoring the merge locally). I checked in just to confirm what I was seeing and yes there was no resolve conflict needed, TFS thought everything was ok, but my modified local file just blatantly overwrote the modified version in TFS effectively discarding the whole client-site change (just like if I'd chosen resolve conflict keep mine - however it never asked me about the conflict or suggested that there was one, just silently lost it)
If you eye-ball the changes before committing you can see that the changes you are making are more than you thought - i.e. the client site changes are effectively being removed and will show as differences - however it's easy to miss this when you are doing it a lot.
I had previously thought to blame coworkers when they skip out my changes this way, but now I've actually seen myself do this to myself I realise the tool is deficient. Hard to believe but there is obviously something wrong with the way it merges your locally changed file against the 'get latest'. I'm using a cloud TFS with a flaky network connection sometimes - I'm told this contributes to the issue.
Does a feature like "TFS auto-checkout before checkin" exist, so that I don't checkout any file until the moment I say "checkin", e.g. in case I only change files temporarily - which happens all the time.
In other words, client-side I want to work as if using subversion, regardless of what the TFS server might think. This must be possible, I just wonder if it is easy to setup.
In yet other words, until and unless I say 'checkin', other users shouldn't (be able to) bother what files I'm editing.
These answers are fine assuming you always work in Visual Studio. But imagine the scenario of editing a bunch of files outside of Visual Studio and you want to use Windows Explorer TFS powertools to automatically checkout files which were just modified. Well, there is no automatic checkout. What I ended up doing was to sort the files by the "Date Modified" column and then individual selecting the modified files only. You can't select any files which might be added, as the TFS power tool Windows extension will grey out the "Check Out for Edit.." The other frustration is that TFS power tools doesn't have a file icon to differentiate if a file is currently checkout or simply not yet added to TFS. Basically, TFS is terrible working with more than file at a time unless you are exclusively working within VS, but who does that.
SVN kicks TFS when it comes to this type of scenario.
You can tell Visual studio not to check out on edit, go to tools, options, source control, environment. Then select the behaviour you want. If you choose editing to "do nothing" and saving to "prompt for checkout" it should be pretty close to what you want.
You could also look at svnBridge which allows you to use TortoiseSVN with TFS. I assume that the point of svnBridge is to allow developers used to SVN to use TFS without having to change the way they work, so it should meet your needs.
A combination of both of these should get you close.
From time to time I hear from people who dislike the automatic check out behaviour common with TFS. One of the great things about TFS is the the pending changes list that shows you the files you have currently checked out and allows you to easily undo any un-intentional check outs. While I personally find the auto-checkout features a productivity boon - like most things there is a preference that you can use to adjust the default behaviour if you find it causes problems with the way you like to work.
In Visual Studio 2008 (with the Team Explorer 2008 installed), go to Tools, Options, Source Control, Environment and change the Checked-in items for Saving and Editing to "Prompt for check out" rather than the default which is "Check out automatically".
No. When you check in TFS will checkin those files, you have to just undo those files.
However checking out a file doesn't stop others from checking them out, unless you've locked them. This non exclusive locking is the default behaviour.
No. But you can do one thing - Open solution in 2 Visual Studio, One in which solution is Online and another in which solution is offline. Do all your changes/work on Offline solution. After completing your task.
Go to first VS (Online) and checkout the files containing your changes.
Go to Second VS (Offline, containing your changes) - It will prompt for file changes and click "No to All" so that all your changes persist.
Press Save All.
First Solution (Online) will prompt for new changes and click "Yes To All" so that all your changes done in offline mode will get in new files.
Get Latest. - Any conflicting changes will be reflected (Try automerge - if you're lucky will work perfectly)
CHECK-IN
Though a tedious task but a workout for your question.
I have to use Team Foundation Server 2010 at my company and I'm not very happy with it.
There are so many features or just default behavior I'd expect from a CVS that TFS seems to lack (compared to svn, git or perforce, which I have experience with), so my question is: which tricks do you know, which hidden features are out there to make TFS easier to use / more convenient?
Perhaps I should elaborate a bit and list what I think could be better:
The default check-in action when associated with a task is "resolve", though in 99% of all check-ins, I only want to "associate" my commit with the task. There's only 1 commit (the last) that "resolves" the task, so why is that the default? Can I change that?
In the check-in dialog, when double-clicking a file, Notepad is launched and shows the contents of the file. Notepad. Seriously? What about the Visual Studio editor? Anyway, I'd like to see the differences to review the changes I've made, not the contents of the file. The diff tool is hidden in a submenu. This might seem trivial, but when I have to check 10+ files it's just annoying to always right-click, open submenu, click to diff.
The diff tool. Merging with it isn't really straightforward, also the conflict detection mechanism is somewhat lacking. The (Tortoise-)SVN / Git merge tools or that of Perforce are way better here.
Speed. Creating a new file, opening a file for the first time, comparing a file with a previous version etc takes forever (that is, 3-10+ seconds). Our TFS server is in-house and has absolutely no load - also why does Visual Studio have to contact the TFS server when I just create a new file (which I might not even check in)? Is there perhaps an option to turn that off?
Readonly files. All files are read-only when checked-in and become writeable when edited for the first time. This is really annyoing when the application crashes because of that. Windows Azure for example modifies a web.config file and fails whenever I check out because the file is read-only then.
These are just the most prominent things that I think are really annoying and unnecessary.
I didn't have the pleasure to branch and merge yet, but from what I've heard so far it won't be very enjoyable as well...
So again: If you know some tricks, settings, featuers that make working with TFS less inconvenient, please share them.
1) is customizable if you reconfigure the work items. (You can also change any combination of fields/states/available values/etc.)
2) is a pain, but if you use the dockable "Pending Changes" window instead then it'll open the file in the editor. I suspect this is a drawback of the Checkin dialogue being modal.
3) you can customize - the option's a little tucked away, but it's on Tools/Options dialogue under Source Control/Visual Studio Team Foundation Server/Configure User Tools. Some third party tools (like BeyondCompare) have pages on their website with details of how to configure them with VS.
4) I've not seen the speed problems, although I do agree about the overhead on creating a file. Not sure if that's configurable.
For the #1
The solution in TFS 2010 is not the greatest one but it works. You need to modify the registry key on your machine as follows:
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\Behavior
Change ResolveAsDefaultCheckinAction to False
TFS Power Tools might be a useful extension for you.
http://visualstudiogallery.msdn.microsoft.com/en-us/c255a1e4-04ba-4f68-8f4e-cd473d6b971f
For #2, are you using the "pending changes" window in Visual Studio to keep track of files that are modified? Double clicking on a file there keeps you in the Visual Studio editor.
For #5, make sure Tools->Options->Environment->Documents "Allow Editing of read-only files; warn when attempt to save" is checked.
TFS is hella frustrating. Good luck!
For #2 there is a registry edit you can make so double clicking launches a diff, vote for the answer here - Compare files on double click in Pending Changes view
1, Bash head against wall
2, Say outloud - it's better than SourceSafe
3, Repeat
4, Install git, or mercurial, or just about anything else.
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?
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 good jumps forwards with 2010, 2012, 2013
TFS is highly accessible for custom tools. There's a rich API that makes it so easy to write dashboards and other tools to get at the data in TFS. And as all the data is stored in SQL, you can browse it and query it directly if need be. I've worked with many different SCMs over the years and have never found one that is so open and accessible - everything (user stories, tasks, bugs, issues, test plans, iterations, source code control & branches, builds, unit testing, continuous integration) is just there at your fingertips. This is an awesome feature of TFS. A lot of the UI failings of TFS have been addressed in a few afternoons writing tools and a dashboard for my team to use. And let's face it, if you write your own, it does exactly what you need.
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. In 2010 onwards it no longer crashes, but it often doesn't correctly check in the changes, so you have to go in and clean up a mess of missing and incorrectly named files.
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 (but is improving, at least on the web-access side). Sure, it works, but there is so much that could be done to make it efficient, pleasant, and more foolproof to use. e.g. [prior to 2012] 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][edit: in 2012 it's much better, but they've gone mad and rolled all the separate TFS dialogs into a single window, which was a serious step backwards. The pending changes window doesn't work nearly as well as in 2010 - it is harder to find things, it takes more clicks to achieve the same things, and if you check in a file from anywhere all the currently 'included' files get chucked into 'excluded' so if you have several things on the go they all get mixed together]
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. [edit: This is getting better with 2010/2012, as you can see workspaces on other PCs and copy and paste them more easily, but it's still a pretty clumsy UI]
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. [still very poor in 2012]
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][In 2012 there have been further improvements, but they are still 'ok' rather than good]
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). [Edit: In 2012 they have fixed this problem. Now every time you switch to the pending changes view it spends 15 seconds refreshing (in 2010 it cached it and showed it instantly but it was occasionally out of date)]
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. [edit: Big improvements were made in 2010 and 2012, but merging is terribly supported - it is really labour intensive. Just little things like only being able to merge a contiguous set of changes, so if you want to merge 5 changes that are not contiguous you have to do them one by one, but each time you open the dialog it starts from scratch instead of remembering where you were, what you last merged, the list of availablke changesets, etc. You should be able to select any changesets you want and it should automate the rest]
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][Fixed in 2012. Hurrah!]
[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). It would be so easy to fix the sln format to make the files mergeable.
[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.[2012: Sorry, can't tell you if this is fixed, as I haven't used this feature since 2008]
[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.
[edit - added 12/2010] When you Get source code, especially when resolving merge conflicts, other windows are often brought to the front (either the Solution Explorer jumps in front of my Pending Changes view, which I have docked in the same tabbed area, or the Source Control window vanishes behind another document window. This is really annoying when you have another file to merge or another folder to Get, as you have to keep "finding" the Source Control/Pending Changes windows. Getting code should not constantly reorder my document/tool windows.[2012: Still broken]
[edit - added 1/2014] With TFS 2012/2013, there is a choice of Server or Local workspaces. Server is the name for the old system where you must be online with the server to check files out. Local is the new default and makes a copy of the entire source repository on your computer, allowing you to make edits to any files without needing to check them out first. TFS then diffs your files against its local copy to work out what you changed. This sounds good, and for many people it probably is good, but it has some serious drawbacks that you should be aware of:
As you no longer check out files, they do not get locked when you edit them, and thus several people can edit any given file simultaneously, requiring a merge operation when they check in. This is fine for text-based source code files, but results in difficult situations or lost work when the files are unmergeable. Unmergeable or non-automatically mergeable files include Solution, Project, Resource (resx), XAML and any other XML files - so this causes a lot of problems in a development environment. If (like us) you also want to store Word and Excel documents and binary files under source control, local workspaces are positively dangerous. We have lost several days of work because someone unwittingly used a local workspace and then it was not practicable to merge their changes. You can reconfigure the TFS server to make Server workspaces the default to defend against this.
With Local workspaces you have to keep two copies of everything on your computer. When we upgraded TFS we suddenly found everyone lost 25GB of disk space, and it took several weeks to work out where the disk space had gone! This was a major problem for us because we all use SSDs and it is only now (2014) that SSDs are getting large/cheap enough that we can afford to be so inefficient with our disk space.
In the few weeks that we used local workspaces we had several incidents where TFS corrupted files or lost changes, presumably due to bugs in the implementation. Quite simply, we cannot accept anything less than 100% reliability for our source control system.
TFS is getting much easier to manage; these days if you don't want to customise anything too much you can set up a server in a very short time (hours) and setting up continuous integration builds and backups etc is extremely easy. On the flip side, while I found it very easy to set up backups of a TFS database, restoring that database and getting up and running after our server bricked itself was another matter - it took 4 days to work through all the unnecessary blocking problems (e.g. you have to restore the backup form a network drive, the data can't be local. When I tried to restore the image to the rebuilt server, TFS kept telling me there were no databases that could be restored. When I got past that, TFS wouldn't use the databases because they didn't match the host server (because that server was gone, the OS had been reinstalled). It took a lot of searching and fettling to get the backup to restore. Restoring should "just work"!
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.
Hates
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.
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.
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.
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
I suppose built-in integration with visual studio is nice, if you like that kind of thing (I don't)
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.
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.
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.
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.
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.
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 :-)
Search functionality is not implemented in TFS 2010 ?
VSS we have search in file; TFS 2008 we have search file ...
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.
The lack of rollback has been my biggest pain point.
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.