When I delete a file in the file system, TFS 2013 will correctly show it as still being in version control, but the file will not show as pending delete, and committing changes does not remove the file from the server. If I go to Source Code Explorer, the deleted file shows up as being on the server, but if I try to delete it, I get an error saying The item could not be found in your workspace, which is also correct, but I need to delete the file and I can't find any way to do it. I really do NOT want to have to download each file and manually delete it.
So, how can I get TFS to detect files that are no longer on the local file system and remove them from the server?
Note, my workspace is local, not server. Many sources say that TFS should detect local deletes in a local workspace, but this does not seem to be true, at least, it's not what I'm seeing.
Update: I know that my workspace is local because here's the TFS Workspaces window:
If the changes are not being detected then your workspace is currently configured as a Server Workspace and not a Local Workspace.
If you edit your workspace, click Advanced, and switch the workspace type to Local.
Note: You can check the configuration by looking for the hidden $tf folder in the root of your workspace...
Use /deletes with the tfs power tool: http://blogs.msdn.com/b/buckh/archive/2005/11/16/power-toy-tfpt-exe.aspx#Online
Is there a way to tell TFS that one or more files has been moved/renamed by another application (in our case, WebMethods 9) running in Eclipse? We have to move/rename the files using WebMethods and not TFS, because WebMethods does a whole lot of automatic reference updating. However, we haven't found a way to tell TFS "hey, trust me - I moved/renamed/deleted it outside of TFS". Instead, it refuses to commit any changes back to the repository until the old file reappears.
We're working around this at the moment by creating dummy files with the old name and then deleting them again via TFS, but you have to agree that kinda sucks. I'd be happy to treat a move/rename as a deletion of the old filename and creation of the new filename; I just don't want to have to fight TFS over it.
Eclipse: 3.6.1.M20100909-0800
TFS plugin: 11.0.0.201306181529
It depends on whether you use server workspaces or local workspaces.
In a server workspace, TFS requires that you inform the server for every change - to check out a file, rename, delete, etc. This allows TFS to avoid scanning your disk for changes, which is beneficial for large repositories. If you want to force a disk scan with Team Explorer Everywhere, because you may have made some changes outside of Eclipse, you can go to the Actions menu and select Detect Local Changes.
In a local workspace, TFS will examine your disk for changes every time you look at the pending change status. So all you have to do is run tf status or click refresh in the Pending Changes View to see changes made to files outside of Eclipse.
If your workflow involves files changed outside your IDE frequently, I would strongly recommend using local workspaces, however this requires TEE 11.0 and TFS 2012 or better.
I have a huge repository. A while ago a file with the name FooBar.xml was deleted from some unknown directory in the tfs. What would be the easiest way to find the file? There are thousands of directories in the repository, so manually inspecting each and every one looking for deleted files is not a feasible option.
From a Visual Studio Command Prompt use the command
tf undelete $/TeamProject/FooBar.xml /noget /recursive
This will undelete any files in the repository with the name FooBar.xml, and leave the undeletes as pending changes. If you can narrow it down to a particular branch or area of your repository that will speed things up.
You can then go though the list of pending undeletes, identify the file you want to keep and "undo" the other pending changes.
Our build person was having issues compiling some source code that is checked into our TFS instance.
I was working on some changes that I was not ready to check in so I made a manual backup of my local folder and deleted the contents of my local folder. Then I did a "Get Latest - Specific Version , with overwrite" to ensure I got the latest. And made sure it compiled (it did, the issue was a setup issue on the build machine).
So now if I manually rename folders locally to go back to my version I have the problem that TFS thinks I have all the latest source ... which I don't. Files were changed by another developer but since I did a "Get Latest - Specific Version , with overwrite" it considers my code to be completely up to date.
Questions:
Can some how 'tell' tfs that my local versions are not that latest?
(I'm thinking that I might to do this with a TFS cmd line util but not really sure which one)
Was there a different way I should have done this?
Thanks.
You could delete/remove your local workspace.
Source Control Explorer -> Workspace dropdown -> Workspaces -> Remove
If you get specific version of Changeset "1" of your source code, TFS will delete local files, and will believe that you no longer have the latest code in your workspace. Then, when you do a get latest it will actually get the latest.
In future, instead of making a manual copy, create a shelveset. In the "pending changes" window, click "Shelve" and follow the dialogue (in this case you'd not want to keep your pending changes locally). This puts your work on the server in a secure, recoverable place, but without checking it in.
Alternatively, in the workspace dropdown, you can create a second workspace. That gives you two separate copies of the code locally, but also two separate sets of checkouts. This is really useful if you often find yourself interrupting one piece of work to look at something else.
If you do another "get specific" with overwrite, this should still fix your problem.
Do you know which files are changed? Are we talking a lot of files? Or just a few?
If it is just a few, then you should just copy your changed version back in then re-checkout the files. TFS will then register than you have changed those files.
If you have a lot of changed files then I recommend you give the Team Foundation Power Tools (tfpt) Online "Command Line" command a try.
The Command Line Help can be seen here.
Here some more info from Buck Hodges:
Online
With Team Foundation, a server connection is necessary to check files in or out, to delete files, to rename files, etc. The TFPT online tool makes it easier to work without a server connection for a period of time by providing functionality that informs the server about changes made in the local workspace.
Non-checked-out files in the local workspace are by default read-only. The user is expected to check out the file with the tf checkout command before editing the file. When working in this
When working offline with the intent to sync up later by using the TFPT online tool, users must adhere to a strict workflow:
* Users without a server connection manually remove the read-only flag from files they want to edit. Non-checked-out files in the local workspace are by default read-only, and when a server connection is available the user must check out the file with the tf checkout command before editing the file. When working offline, the DOS command “attrib –r” should be used.
* Users without a server connection add and delete files they want to add and delete. If not checked out, files selected for deletion will be read-only and must be marked as writable with “attrib –r” before deleting. Files which are added are new and will not be read-only.
* Users must not rename files while offline, as the TFPT online tool cannot distinguish a rename from a deletion at the old name paired with an add at the new name.
* When connectivity is re-acquired, users run the TFPT online tool, which scans the directory structure and detects which files have been added, edited, and deleted. The TFPT online tool pends changes on these files to inform the server what has happened.
To invoke the TFPT online tool, execute
tfpt online
at the command line. The online tool will begin to scan your workspace for writable files and will determine what changes should be pended on the server.
By default, the TFPT online tool does not detect deleted files in your local workspace, because to detect deleted files the tool must transfer significantly more data from the server. To enable the detection of deleted files, pass the /deletes command line option.
When the online tool has determined what changes to pend, the Online window is displayed.
Individual changes may be deselected here if they are not desired. When the Pend Changes button is pressed, the changes are actually pended in the workspace.
Important Note: If a file is edited while offline (by marking the file writable and editing it), and the TFPT online tool pends an edit change on it, a subsequent undo will result in the changes to the file being lost. It is therefore not a good idea to try pending a set of changes to go online, decide to discard them (by doing an undo), and then try again, as the changes will be lost in the undo. Instead, make liberal use of the /preview command line option (see below), and pend changes only once.
Preview Mode
The Online window displayed above is a graphical preview of the changes that will be pended to bring the workspace online, but a command-line version of this functionality is also available. By passing the /preview and /noprompt options on the command line, a textual representation of the changes that the TFPT online tool thinks should be pended can be displayed.
tfpt online /noprompt /preview
Inclusions
The TFPT online tool by default operates on every file in the workspace. Its focus can be more directed (and its speed improved) by including only certain files and folders in the set of items to inspect for changes. Filespecs (such as *.c, or folder/subfolder) may be passed on the command line to limit the scope of the operation, as in the following example:
tfpt online *.c folder\subfolder
This command instructs the online tool to process all files with the .c extension in the current folder, as well as all files in the folder\subfolder folder. No recursion is specified. With the /r (or /recursive) option, all files matching *.c in the current folder and below, as well as all files in the folder\subfolder folder and below will be checked. To process only the current folder and below, use
tfpt online . /r
Exclusions
Many build systems create log files and/or object files in the same directory as source code which is checked in. It may become necessary to filter out these files to prevent changes from being pended on them. This can be achieved through the /exclude:filespec1,filespec2,… option.
With the /exclude option, certain filemasks may be filtered out, and any directory name specified will not be entered by the TFPT online tool. For example, there may be a need to filter out log files and any files in object directories named “obj”.
tfpt online /exclude:*.log,obj
This will skip any file matching *.log, and any file or directory named obj.
I'm using a hack with opening the solution without network connection (unplug cable, turn off wifi) and solution will be opened in offline mode.
There is also a plugin called "go offline" for that.
And then, you click on "go online" which is automatically displayed, in case of offline solution.
After this, VS will check all your local files against TFS and automatically checkout files which were changed.
But for your case, I would also suggest to use shelvesets.
in TFS 2013+ and VS 2015+ you have Cloak option which deletes local files and cloaks those branches from getting downloaded to your local workspace (basically unmaps specific branches)
We have a new ASP.NET project on VS 2008 environment, and a new TFS server was setup for it, but originally the bin folder of the project also got checked-in.
The team has about 10 active developers at a time and it a big issue now as some of the common libraries remains checked-out by someone or other.
As per the best practice, I now wish to fix this issue and remove the bin folder out of the version control AND I need to ensure that from now on, when a developer checks-in his project, the bin folder again does not gets checked-in. How do I ensure the both things with the correct approach? It would be great if I can do something as an TFS Admin so that from the next day all developers automatically get some settings pulled into their boxes so that they stop checking-in the bin folder once I have removed it from TFS control.
I am a beginner in TFS, as earlier I used SVN primarily, so please point me to the proper steps, documentation. Thanks!
Delete the bin folder in solution explorer, this will add a delete to the pending checkins.
A build should re-create the bin folder, but not add the folder to the project (and thus there'll be no prompting for it to be added to version control).
This won't prevent someone adding it (or anything it contains) back into version control outside of VS (eg. from the command line, or adding the bin folder back into a project). I don't think there is anything you can do to stop arbitrary files being added except training (if your developers cannot handle this, how do they handle all the other "don't do that"s associated with development?)
Updated, since this was written TFS (including VSTS and Visual Studio1) allow files and folders to be ignored via a .tfignore file.
1 Often Visual Studio does not pick up changes to the .tfignore file, needing a restart.