We have a rule in TFS that requires all checkins to be associated with a work item. We have an automated daily build process that uses tf.exe to check in the files. However, I did not find any way to associate files with a work item.
I heard of tfpt, and have it installed, however, I did not have any success using it to associate files with a changeset either.
Is there another way to do this?
Thanks!
I'm pretty sure tf.exe / tfpt.exe cannot do this except through their UI. If you need to use the -noprompt parameter for automation then you're likely out of luck.
Luckily, it's not hard to use the API directly. MSDN link. Basically just build up an array of WorkItemCheckinInfo[] and pass it along with your request.
Team Foundation Power Tools has a command for dealing with work items.
tfpt.exe help workitem
Related
We are using Microsoft Test Manager 2015 Update 1. I created a couple of shared parameters to see how they work.
How do you delete them? I can make them inactive, but they still display in the list of available shared parameters. I don't see a delete button and when I searched online I found nothing about it.
Shared Parameters are stored in TFS as Work Items so you could destroy it (there may be a better way but I don't know of one)
Remove or delete work items
On-premise you'll have to use the witadmin.exe command line tool (%programfiles(x86)%\Microsoft Visual Studio 14.0\Common7\IDE) with the destroywi option. You'll need to know the ID of the Shared Parameter Work Item you want to get rid of.
witadmin destroywi /collection:http://TFSServerName:8080/tfs/DefaultCollection /id:123
I'd like to know if there is some way to make a checkin on a TFS server associated to a Work Item that's on another.
Currently some of our developers use a TFS that's hosted offshore containing the source code and we need to install another TFS locally to use Work Items as a project management tool and for the rest of our developers.
Beeing able to associate the two (work items + checkins) would be nice but I presume it's not possible.
Thanks
Apparently it's not possible: http://social.msdn.microsoft.com/Forums/en-US/tfsgeneral/thread/d3ddf813-dc13-48a2-808e-7887ddc4d9b1
I'm trying to write a very lightweight "build" script which will basically just get a few files from TF (based on a Changeset number). Then I'll run those files in SQLCMD.
I'm using this:
tf.exe get c:\tfs\ /version:c2681 /force /recursive
However, this appears to get EVERYTHING, not just the files in changeset #2681. I'd like to be able to point it to the root of my tfs workspace, give it a changeset number, and have it just update those few specific files. Also, it appears to be getting older versions (perhaps what was current when changeset #2681 was checked in)?
Is there a way to get just those specific files, WITHOUT needing to call them out specifically in the tf get itemspec?
EDIT: I actually had to add the /force option in order for it to do anything at all. Without force, it doesn't appear to even retrieve from the server a file I deleted locally, that's definitely in the changeset.
thanks,
Sylvia
Everything mentioned in Jason's and Richard's posts above is correct but I would like to add one thing that may help you. The TFS team ships a set of useful tools separate from VS known as the "Team Foundation Power Tools". One of the Power Tools is an additional command line utility known as tfpt.exe. tfpt.exe contains a "getcs" command which is equivalent to "get changeset" which seems to be exactly what you are looking for.
If you have VS 2010, then you can download the tools here. If you have an older version, a bing :) search should help you find the correct version of the tools. If you want to read more about the getcs command, check out Buck Hodges's post here.
The TFS server keeps track of what each workspace contains1. Any changes made locally with non-TFS client commands (whether tf.exe, Team Explorer or another client) will lead to differences between the TFS Server's view and what actually exist.
The force options on the various clients just gets everything removing such inconsistencies (effectively resetting both what is on the client and what the server thinks is there).
When you perform a get against a specified version (whether date, changeset or label) you get everything up to and including that point in time, whether on not specifically changed at that point. So getting
tf get /version:D2012-03-30
will get changes made on or before that date.
To get only the items included in a changeset you'll have to do some work yourself, using a command to get a listing of the content of a changeset and parse that to perform the right actions (a changeset can include more than just updates and adds of files2).
It seems to me that if you want to perform a build at each changeset affecting a particular TFS folder you would be better off looking at using TFS Build which is all about doing exactly that – avoid reinventing the wheel – and focus on the build part (other continuous build solutions are available).
1 This will change with TFS11 local workspaces.
2 Eg. handing the rename of a folder will take some non-trivial work.
The command will get all the sources for the given changeset. By default it will only get the files that it thinks are different between your workspace and the server. However, by using the /force option you are asking it to get everything regardless of the state it thinks your workspace is in (which is much slower but has the benefit of ensuring your workspace is fully in sync with the server).
So just removing /force will probably achieve what you want.
edit
As I said above, tfs will get all files that it thinks are different from the server. If you manually delete a file from your local workspace, TFS won't know that it is missing from your local version, so it won't think it needs to update the file. There are three solutions to this:
Use /force to make sure things are in sync, and put up with it being very slow.
Don't modify files in your workspace with anything other than TFS tools (tf.exe, Visual Studio, TFS power tool for the explorer shell). You shouldn't just delete files on your local hard drive - if they really need to be deleted, then delete them in source control.
Go offline in TFS before you make changes manually. Then when you go online, TFS will search for all the changes you have made and add them to your pending changes so that TFS is aware of them.
I have been using SourceGear vault for some personal projects and Team Foundation Server for work projects. One thing TFS is missing is a simple feature that Vault has on its check in dialog window.
In the Vault client, you can see if the checked out file changed from the previous version checked in. Here is a screen shot. Notice the column "Details"? That tells you there is a difference. The way this is super helpful is if you have to check out a entire project because you are going to do code re-generation. I'll check out my class library project and then regenerate my CodeSmith templates. Doing this may result in just a few specific files from changing. When I view the pending check-in screen, I see the files that really changed and I can compare to see the impact.
SO... can TFS do this? Maybe there is a 3rd-party tool that will do it for me? Is there a TFS SDK or PowerTool that I have to get. Anyone want to build it?
Select all the files in "Pending changes" window and activate the context menu. Then click "Undo..." > "Undo Changes" > "No to All".
The files without changes will be rolled back.
Per this page, you can run this command from the Visual Studio Command Prompt.
tfpt uu /noget /r *
You'll need to have TFS Power Tools installed for this to work. Also, make sure you browse to the root of your mapped folder within the command prompt (ie - C:\TFS for example).
TFS Power Tools links (if you don't already have it)
TFS Power Tools for 2010
TFS Power Tools for 2012
There is no need to undo the unchanged files, as TFS will notice they're unchanged upon checkin and will only associate the truly changed files. Any files checked out but unchanged are reverted to their last known checked in version and will not be associated with your checkin. It is impossible in TFS (though not very clearly documented) to check in an unchanged file. It will always revert to the previous version if there are no changes.
You can quickly undo your unchanged files by calling 'tfpt.exe uu /r' from the command line (you need to have the Team Foundation Power tools for this) or by using the "Undo unchanged" button in the Pending changes window. This removed any items from the list that are unchanged immediately. So that you can see exactly what you're checking in.
Though it might be that this option is added by the Team Foundation Power Tools or the TFS Source Control Explorer Extensions (which are a must have for every TFS user anyways).
See also:
https://stackoverflow.com/a/2100981/736079
https://stackoverflow.com/a/6387656/736079
https://jessehouwing.net/vsts-tfs-why-i-like-them/
I don't like answering my own questions, but it looks like there might not be a real Microsoft solution out there. For me, this is how I handle the problem at the office using Visual Studio.
Before I re-generate the business objects, I make a copy of the entire folder structure
I check out the entire project or the root generated folder
I start the code generator. Sometimes, I know exactly what is changing, but other times, I might make a lot of changes and I don't want to miss anything. My code generator at work also generates all the SQL files needed to DROP / CREATE stored procedures.
Using SourceGear DiffMerge, I compare the folders of the just generated and the previously backed up folder.
This is pretty time consuming. I never thought of it as a problem until I saw Vault identifying that a file was different on disk from the repository.
Maybe you all can say how you do code generation / regeneration when working with a source control repository.
I work in a corporate development environment where many developers may be working on the same file, and we have TFS as our source control as well. In our document of Best Practices for TFS, we really discourage checking out files that the developers don't intend on changing, that way we naturally exclude files without differences when submitting a changeset.
To answer your question, I normally just look at the "Pending Changes" window and run a Compare on the "changed" files that I'm unsure of--the Compare tool should immediately tell you if your local copy is the same as the server copy. Unfortunately, there's no real workaround other than what I suggested, but I don't see the scenario where I absolutely must check out an entire project branch for editing.
Is there a chance to delete Work Item from TFS, or all I can do is just to rename it.
Update:
This question was for TFS 2008.
New version (2010) have out of the box solution as Rob Cannon suggested
The answers here are obsolete for TFS 2010. You need to use the 'witadmin destroywi' command now.
http://msdn.microsoft.com/en-us/library/dd236908.aspx
See this tool: http://devmatter.blogspot.com/2009/04/deleting-work-items-in-tfs-ui.html
the Team Foundation Client does not include any functionality for deleting work items from TFS.
Although it’s a tad inconvenient, you can delete work items from TFS by installing the Team Foundation Server Power Tools (October 2008 release or greater). Of the many features available as part of the power tools, there is a command called destroywi that can be used to delete work items. For example, to delete the work item ID 1234, use the command:
tfpt destroywi /server:tfs-dev /workitemid:1234
Although this is a relatively straightforward task to perform, not everyone is comfortable with the command line interface not to mention you have to look up the work item ID(s) ahead of time. To ease the process a little bit, I created a simple UI that sits on top of the Team Foundation Server Power Tools that allows you to easily select a Team Foundation Server and Project to query from. You can run an existing query to display a list of work items from which you can select one or more work items to be deleted. You can also enter the work item IDs directly (as a comma-separated list) if you prefer...
No one added code or an example, so here is my re-iteration of this answer using Rob Cannon's answer as guidance above.
This is batch file code for accomplishing this task. You will be prompted before you actually delete your Work Item.
ECHO OFF
SET "VSDir=C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\"
CD %VSDir%
SET /p WorkItemID=Enter Work Item ID:
ECHO.
witadmin destroywi /collection:{TFS Server}/{Collection Name} /id:%WorkItemID%
ECHO.
PAUSE
Enjoy
If you want to do this without using the tool suggested in the accepted answer, here is a quick summary of what to do. This is based on the corresponding MSDN article suggested in another answer.
Open Visual Studio Command Prompt:
Using the start menu:
Search for it.
Or navigate to All Programs -> Microsoft Visual Studio X -> Visual Studio Tools to find it.
Invoke witadmin
Determine the team project collection URL. An example is http://ServerName:Port/VirtualDirectoryName/CollectionName.
Determine the work item id.
Invoke the following command, substituting the two above values:
witadmin destroywi /collection:CollectionURL /id:id
See the MSDN article for more details. Note that you need permission for this to work.
You have to use the TFS Power Tools.
http://msdn.microsoft.com/en-us/vstudio/bb980963.aspx
1) As mentioned above the destroy command (pretty tiresome if you have to delete more than a single item)
2) With TFS 2015.2 you get a new recycle bin function (without an option to permanently remove the items).
https://www.visualstudio.com/en-us/news/tfs2015-update2-vs.aspx#delwork
But since they dont appear anywhere (replaces the "Removed" State) and they can be restored ... compared to the fact that it took since 2008 to add the bin feature .. pretty neat id say :D