One of the questions that came up from one of our users was "how do I delete the files from my local file system - and tell Team Foundation Server that I have done this".
The first thing you might try is to just delete them locally. However, Team Foundation Server (TFS) uses your workspace to keep track of what files you have downloaded and what version you have of them. The reason it does this is so that it can maintain your files without a costly (both in terms of network and CPU processing) sync step. With TFS, when you say "Get latest", you only get the latest version of files that have changed since you last got them. Nothing is downloaded that you don't need (thereby saving you network traffic). A really neat thing about TFS is that if you delete a file on the server and check that delete in, then when somebody does a "Get Latest", the file is deleted on their local system as well - very nice. Moves and renames also exhibit this behavior - really useful for keeping the local file system in sync with the servers.
But, if you have deleted a file locally (using Windows Explorer for example) then do a "Get Latest" the file is not downloaded - because the server thinks you already have it. You can easily download the file by going to "Get Specific Version..." and selecting the "Force get" option - which will download all files, regardless of if the server things you have them or not.
The question I was asked was how to tell the server you have removed the file from your system, without deleting it from the server. In the end, it took me a while to figure out the answer (and the help of Buck Hodges)
The answer is, if you do a "Get Specific Version..." on the files, and select Changeset 1, the files will be deleted locally and the server will know this. The color of the file in the Source Control explorer will go from black to gray and will have the phrase "Not downloaded" in the latest column.
Changeset 1 is a special changeset on your Team Foundation Server instance. It was created as part of the setup routine and only contains one thing - the root node ($/) in your source control tree. If you do a get for changeset 1 on any actual files then they will not exist at that point in time on the system so will be deleted locally and the server will know this.
Anyway, I thought this worthy of a TFS Tip post. Not only because it highlights how to do something that is non-obvious, but also because once you understand how it works, you will understand a large part of what you need to know about Team Foundation Server Source Control.
Great tip Martin! I've always wondered about this one but never tried to find out.
One of our users complained about having TFS removed his local files and that a Force Get did NOT retrieve any files at all.
Turned out that in his workspace he had mapped his local folder to a non-existing folder on the Server (via direct edit; not using the Browse button)
Something like:
Active ...... $/'root-folder' ...... W:\Main
Active ...... $/'non-existing folder' ...... W:\Main\Library\Library1
When getting the latest version of Libary1, TFS decided that there were NO files in the specified server folder (because it didn't exist) and removed all files on the local folder (W:\Main\Library\Library1). A Force Get did not retrieve any files.
When the 'invalid' mapping was removed, a Get Latest retrieved all files.
So, I guess this mapping acts like a 'cloacked' folder and effectively removes the files from your local folder.
Hi
This method is not working with TFS 2008(using VSTS 2008 at client side), any idea about that ???
Works on all my machines - what is happening for you?
Thanks for your help.
I usually just go into the Source Control pane (from Team Explorer) and delete it there, it tracks all changes even if the files aren't in your solution (in my case, Sandcastle content files).
Kamran - that is a great way to delete the file from both the server and your local file system. What this tip was explaining was how to delete the files locally *but not* delete the server version. Apologies for the confusion.
How does this relate to "cloak"?
Cloaking a folder or file in the workspace tells TFS that when you do a get latest you do not want to include a particular file or folder. Cloaking something that was previously included in the workspace will have the affect of it being removed from your local file system and TFS knowing that so it works as you would hope. Cloaking is most useful when you want this to be a more permanent arrangement - i.e. give me everything in the $/TeamProject/main/source folder apart from everything in the $/TeamProject/main/source/HugeBinaryFiles folder because that folder doesn't affect what you are working on and you don't want to have to pay the penalty of downloading that folder or keeping in sync with changes to it.
Hope that helps,
Martin.