How to make TFS reflect file-system changes, not solution explorer

Question

I'm fairly new to TFS, coming from a a CVS and Subversion background, with some Git and Mercurial influences. I find that I am often fighting with it because it doesn't compare the state of your working copy on the file-system with that in version control. Instead, it shows you what it thinks is the file system state, based on what you've done in Solution Explorer and Visual Studio.

For example, if you delete a file in Solution Explorer and, later, replace the file in some other tool (usually Windows Explorer) TFS will insist that the file is deleted. Further more, it will 'detect' the replacement and suggest it as an 'Add' but it won't let you promote that because the 'Add' conflicts with the 'delete'. There is no easy way to resolve this because you can't undo the 'delete' either - you can't undo a 'delete' if the file is physically still present on the file system!

This, in my opinion, is a disaster. Why can't it just forget what you have previously done in Solution Explorer and show you the current state: i.e. the file has merely changed (or remains unchanged.)

Similarly, if you edit a file in Visual Studio and subsequently edit it to undo those changes, TFS insists that the file has been modified, sometimes, even if there are no effective changes - the committed revision is identical to the new one after your changes.

Is there any way to break this link and disable tracking of you actions inside Visual Studio - i.e., when you refresh 'Pending Changes', it looks at the current state of your working copy on the File System and diffs THAT with the head revision?

Answer 1

This doesn't have anything to do with Solution Explorer, per se. Team Foundation Server, when it operates in "Server Workspace" mode is a checkout/edit/checkin type of source control system. This means that you must explicitly inform the version control system that you are making changes. This allows it to scale to very large repositories, since it does not have to scan the filesystem, like an edit/merge/commit (like TFS "Local Workspaces" or Subversion) would, or like a distributed version control system (like Git) would.

Visual Studio or Eclipse will interact with the source control system, so that when you start editing (or delete, etc) a file then it will inform TFS of your changes so you do not need to make these changes manually. If you interact with your working copy from another program (Windows Explorer, Notepad, etc) then you will need to manually pend those changes with the tf command-line client or with Source Control Explorer.

If you find this frustrating and do not require the scaling abilities of TFS Server Workspaces, then you can use a TFS Local Workspace, which will scan the filesystem and notice any changes you make outside of your IDE. Or, of course, you can use the Git support built in to Visual Studio and TFS 2013.

Answer 2

If you're using TFS 2012, you could use a local workspace: this uses the local file system in a way more analogous to SVN, although it may not match it in every way..

Note that if you have more than 50,000 items in your workspace, this is not advisable due to performance considerations.