Is there any mechanism available (preferably through the TFS API) to delete the drop output of a deleted build?
We have a number of deleted builds were the drop output still remains, as a result of the retention policy of the build definition in the past not being set to delete "All".
Querying the relevant builds and "redeleting" with IBuildDetail.Delete() or IBuildServer.DeleteBuilds(builds) has no effect (which one may expect), nor does IBuildServer.DestroyBuilds(builds).
Is the only option to get the drop location from the IBuildDetail and use the standard System.IO file/directory classes to perform the directory delete?
That would be my guess. At this point those folders are just regular old windows folders, since the build(s) they were linked to no longer exist. So I would expect to use a regular old delete folder command if I wanted to delete them.
The "Community TFS Build Manager" extension provides this functionality. Just delete your build and it will remove the contents from the drop folder as well.
http://visualstudiogallery.msdn.microsoft.com/cfdb84b4-285e-4eeb-9fa9-dad9bfe2cd10
Related
I have a build process that I've defined with a custom build process template, and I'm looking for some advice on how I can solve a problem I've run up against.
The build process (TFS 2012) is used to build the code that drives our load tests, and I have a separate process that needs to reference a specific path within the drop folder so that it is always using the latest version of the load test code. Automated load testing, pretty standard stuff.
However, I'm wondering if there is a way to get the TFS build to overwrite files it finds in the drop folder. Right now I have it set up to drop to a very specific folder, and not put anything that would change in the folder name (no build number, date, etc.). The thought is, this way the automated utilities that rely on those files have a fixed point to look at.
However, when I currently run the build it gives me error TF42064: The build number '<build>' already exists for build definition '<build>'.
Currently I have the build definition set up to only retain the latest build, because this process is specifically for those automated tools. We have other build processes that are fired for debugging/troubleshooting/logging purposes. Is there a way to get the build definition to overwrite the drop folder each time, or will I have to dig into the .XAML template file to have it delete the folder it finds before the build fires?
The way I approached this requirement was to start with the default template and let the build copy to the normal drop location which allows me to keep historical builds in the same way as all other builds.
Once the build has been completed I then copied to a single drop location from the standard drop location by extending the standard build template, the activity was added just before Check-In gated changes.
The steps involved were as follows:
Within SharedResourceScope:
Delete Unified Drop Location
Create Unified Drop Location
Copy Directory (source: BuildDetail.DropLocation)
By default TFS Build creates a new folder, using the unique build name/number, and drops the files there.
If you want to change this behaviour to overwrite files in a known location (instead of creating a new folder each build) you need to modify the build workflow/XAML (as #Oswald mentioned in the comments).
You can read about customizing TFS Builds from the ALM Ranger Build Guidance on CodePlex: http://vsarbuildguide.codeplex.com/
I'm part of a large project mapped from TFS, within that project there is a folder which I have finished working on. I don't want that folder anymore so I'd like to delete my local copy. The problem is that TFS wants to mirror the change and delete the folder from source control, I don't want to remove it from TFS.
The only way I can find to do this is to unmap the workspace, and then go through and get all the other folders I need to work on.
Is there anyway I can just delete that folder locally?
This is an older post, but since the only given answer seems "not entirely correct" to me I'd like to answer anyway:
I blogged about this (in german) here: blog.nils-andresen.de
If you have a local copy, that you want to un-get or un-download like this:
simply right-click the folder and then click "Get Specific Version" or "Advanced > Get Specific Version" and specify Changeset 1.
Here's why from Martin Woodward's TFS Top Tips:
...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.
When the process is complete the "Latest"-column will show "not downloaded".
After that any remaining files in the filesystem can safely be removed.
You can cloak the folder in your local workspace.
By setting the working folder status to Cloaked, you can specify that a local folder should not copy files from the server when you perform a Get operation. You might choose to do this to conserve space on your local disk. If you later decide that you need to get files in those cloaked folders, you must change the status to Active and then perform a Get operation.
Just started up Visual Studio 2012 and opened my solution which is in source control with Team Foundation Server 2012 Express and encountered this, any ideas? Can't get latest, can't check in, everything appears checked out :( Basically my workspace is unusable right now.
TF400018: The local version table for the local workspace MY-PC;My
User could not be opened. The workspace version table contains an
unknown schema version.
There is only one post I could find on the net, and the answers are pretty vague.
I had the same issue, and I just fixed it on mine.
If you don't mind re-map all your projects, you can try follow:
Click the box in "Workspace".
Click on "Workspaces".
Delete the workspace profile you're currently using
Re-connect to TFS open "Source Control"
Be aware that you may lose all your TFS mappings, you may need to re-map all your projects from TFS. Backup your changes that not checked in yet.
cycle6 is correct, but it isn't clear that you will not lose your pending check-in list if you follow some additional steps.
Click the box labelled "Workspace".
Click on "Workspaces".
Delete the corrupt workspace profile, accepting the warning.
Re-connect to TFS and open "Source Control Explorer"
Create a new workspace
One by one, map your projects to the same folder as before
You will be presented with a list of conflicts, where you have matching writable files in the folder already.
Choose "Keep local copy" for each file you had checked out before, and "Take Server Version" for any files changed by other members of the team that you didn't have the latest version for. This might take a while depending on the length of the list, but it is worth comparing versions for any file you are unsure of.
You will be left with your solution and all pending items marked as checked out, with your work preserved.
I did the following steps and it solved the issue:
deleted the hidden folder named $tfs and then
in the Visual Studio, Solution Explorer: Right click on the solution node > the Source Control > Get Specific version > latest version
If you already have multiple instances of Visual Studio open.
Close all of them . [in some cases you need to log out from windows & log back in OR restart ]
Rename the $tf folder with any other name (eg. $tft)
Start Visual Studio, to see your issue fixed. :)
Hope this helps.
Sometimes this happens when you are running out of disk space.
Try to see if you have very low space, eg. < 10 MB.
If that so, try to clean up your windows Temp folder. See if that solve this issue
It's a misleading message to an extent.
What has happened is that the internal data structures of the workspace have become corrupt.
The ends up as the code (in the tf command, Visual Studio, et al.) to load those data structures failing to load from the relevant files, which becomes an error about a schema version problem.
In the case that I experienced, this was because the machine hosting the workspace ran out of disc space while doing operations upon the workspace of various kinds (check-outs, check-ins, adding pending changes — it was actually a bunch of workspaces being used by TFS 2017 build agents and multiple active builds).
This corrupted parts of the data that are held in the files under the hidden $tf subdirectory (it always being a local workspace on a TFS 2017 build agent), because source control wasn't able to rewrite/extend these files.
Other answers here discuss partly retaining some of the files, based upon more specific knowledge of what has not been corrupted (such as preserving the internal files storing pending changes if one wasn't creating any pending changes), but the basic idea is that one needs to reset all of the stuff in $tf to a sane state of some kind.
In my case, I had the disadvantage of multiple potential causes and no consistent knowledge of which parts of $tf were corrupted, but I conversely had some advantages:
It being a TFS build, arranged to build from the build agent's s (source) directory into its a (artifact staging) and b (binaries) directories, there were not masses of non-source-controlled object and other files in the workspace (which is the s directory) that would have ended up as pending additions.
There were not any pending changes (to actual source files) worthwhile to preserve. I could afford to lose all information about source files, and indeed all current locally-stored information about the workspace, and simply run the build again with a fresh sane and largely unpopulated workspace. I did not even need to restore source files and directories for the whole workspace, as the first task in any TFS ("vNext") build is a "Get Sources" task that uses (variously) tf vc scorch, tf vc undo, and tf vc get to check out the right source version.
So simply, in Developer PowerShell (Visual Studio being installed on the build machine):
Remove-Item -Recurse -Force 'X:\Agents\07\_work\1138\s'
tf vc get 'X:\Agents\07\_work\1138\s'
(Note that one can always get at the tf command in some way on a TFS build machine. Every build agent has a local helper copy of tf.exe and its ancillary DLLs in its VSTS "OM" subdirectory.)
I possibly could have omitted the tf vc get step, but having had trouble with "Get Sources" in the past I do not trust it to robustly cope with arbitrary manual external alterations, such as no s directory when the build isn't configured to outright delete that entire directory itself (as it can be but was not here).
For the same reason, Microsoft's own "agent maintenance" (another way to clean things up) is quite dodgy, and ends up leaking workspaces on the TFS server (which I have raised a bug with Microsoft about).
There is simple workaround. Remove local mapping to folder where is the sources (Advanced -> Remove Mapping, or just rename or delete mapped folder. After that you will be able to connect to tfs. Download the project again.
If you already have multiple tfs instances of Visual Studio open.
1.) Open File -> Source Control -> Manage Workspaces
2.) Delete all tfs map
3.) Then select folder maps
For the same issue in eclipse: Find the folder $tf and delete it.
You will find the $tf folder in the workspace directory. If not then search for the $tf folder.
Once you have found it, delete it.
In my case, none of the other answers helped - the problem was occurring on a machine that didn't have Visual Studio and no matter how I tried to get rid of the bad workspace data it never worked. After working with procmon a bit, I discovered another critical folder that might be the source of this error: C:\Users\All Users\Microsoft Team Foundation Local Workspaces\ (it might also be under C:\ProgramData (on my system, 'All Users' is a symlink to that folder, but not sure if this is typical.) In this folder there are sub-folders named like guids that contain some other folders, one per workspace it appears. In my case, some of the data in these folders was old and some was corrupt. Once I deleted the bad workspace folders, all my problems disappeared. You might also want to delete the Cache folder as identified in the comments of this post, but that didn't help me (didn't seem to hurt though, either.)
Alternatively, you could just backup your current workspace to a different location, re-create your workspace, and copy the files back that you had made changed to. VS should detect the newest files and automatically check out these files allowing you to check in the newer versions that you copied back from your backup.
What worked for me is, delete the local folder(s), restart your machine, then map the projects again. Any pending changes you have just save them somewhere else temporarily.
I have several projects in TFS which visually appear in the directory hierarchy as grayed out. When I browse within the projects in Visual Studio 2010/Source Control/TFS 2010, I notice that all of their contents have a Latest value of "Not downloaded". Normally, I have only seen Latest values of "Yes" or "No".
I have tried all of the varieties of "Get latest" that I know, but I am always alerted that "All files are up to date".
If I try to "Check out for edit", I am not allowed.
When I observe the properties of these grayed out files, they always say Workspace Version = "Not applicable".
How do I fix TFS so that I can download and check out the projects again? My suspicion is that my workspace is messed up, but I do not know what to do to restore/reconfigure it.
I was able to remap the directory to fix my issue. To do this, I
selected (right-clicked) the branch that included all of my code, and selected "Remove Mapping..."
renamed the folder I was mapped to within TFS (you can delete it as well, but I renamed just to keep it during this experimental process)
created a new folder with the original name of the branch I was mapped to in the beginning, and
selected (right-clicked) the branch that included all of my code, and selected "Map to Local Folder".
This process forces a complete re-download of the entire branch. Luckily for me, my branch was only 2GB, so I was able to re-download in about 5-10 minutes.
The reason for getting "All files are up to date" - is that the information on the TFS server and the files on your disk is out of sync. If you delete the files on your disk with file explorer - the TFS server still thinks you have the file on disk. To re-sync you have to force an update like this:
Check the two checkbox on this dialog - and click Get:
It happened to me as well when I added and existing project as a reference to another project.
When I added the project reference I had a pop-up message that told me that the current project already exists at the source control but at a different location then the relative path of the current project.
by a mistake I choose the wrong option which lead to the unnecessary mapping.
In order to solve this issue I've removed the mapping from the workspace.
only after removing the mapping i could get the latest project.
I solved it by following this - remove the work space and then tfs prompted me to download everything again.
https://msdn.microsoft.com/en-us/library/ms181386(v=vs.100).aspx
It sounds like the folders / files in TFS are not mapped to a local drive in your workspace.
In Source Control Explorer, select the "Workspace:" dropdown, then select "Workspaces".
Choose your current workspace form the list that appears, then hit "Edit". Check that the TFS folder $/blah is mapped to a local folder c:\tfs\blah
You should now be able to get latest, check out etc.
I had some weirdness with this after :
updating to TFS2017
updating to VS2017
trying to change my TFS URL to https (gave up and reverted back to http)
So somewhere along the line this broke my workspace such that all my projects were showing as unbound. I was able to do a get latest again. This should not overwrite any files you have changed providing they are writable, but if you have any doubt whatsoever then backup your local workspace before doing get latest. It will ask you to resolve conflicts - so make sure to select 'keep local copy'.
In my case, when the branch was deleted: Right click + Check in, helped.
Scenario:
A solution is checked into TFS. Changes are made to an offline/disconnected/unbound copy of the solution, which becomes "the latest" version. I want to update the repo with this disconnected copy's files.
How do I get TFS to look at all the files and determine which ones have changed, so it can check only those in?
If this were SVN, I would just plop the files on top of the existing working copy, and it would just work.
Do you have another copy of the solution that is bound to TFS? If not, you'll need one. You have two options:
Take the solution "offline" by right-clicking on the solution node and click "Go Offline". You can then copy your changed solution on top of the bound solution. When you load the solution again, right-click the solution again and choose Go Online. This will scan the disk and determine what has changed.
You other options is to run "tf edit" recursively on a bound solution, copy your changed solution on top of the bound one and then run "tfpt uu". "uu" stands for undo unchanged and it will undo changes to the files that are not different.
I cant think of any elegant way off hand but your best option would be to know what files were changed or added offline and connect them to the TFS version while removing the old TFS files.
To do this simply right click all of the old files and either delete them or exclude them from the project then move the new files into their physical folders and replace them with the updated version. If files were added then add them in the correct folders. Finally make sure all files are view-able in the solution explorer by clicking "show all files". Finally, right click the files you changed and select include in project for each.
This way you will have replaced only the files that were changed and won't have to check in the entire solution to TFS making it very unclear what files were changed with your check-in.