Given a Team Foundation Server repository, how can I retrieve all checked in versions (or versions later than a specific changeset) of a specific file?
The reason I'm asking is I want to track what versions contain a certain string. So I thought I'd download them all and then grep or similar.
There is no standard way to do it from the UI or the commandline, but it's easy to do from the Client Object Model.
You can use the VersionControlServer.DownloadFile method and supply a versionspec. And you can use the VersionControlServer.QueryHistory method to query all the different changeset versions of the file.
Combined you'd be able to piece together a small Console application or a Powershell script to grab all versions. And grep them at the same time by adding a bit of Regex :).
Check out this blog post to see how to connect to TFS and get hold of the ProjectCollection from which you can request the VersionControlServer object.
Related
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.
Is there a posible to get previous version of code in TFS Build script?
I need to get curren version of config file and version from previous check-in, compare them, check if some files in other folders have the same changes and save the results to log.
We have a similar situation, where we need to get data from a file before getting the latest version. I don't know how much of this is applicable to you, but here's how we do it:
Since we're using CruiseControl.Net for build management, we turn off the autogetsource control in our configurations.
We have built a MSBuild Custom Task (if it's a fairly simple task, you can do it in-line) that retrieves the information we require prior to Get Latest.
"Manually" perform the tf get operation (as an MSBuild task)
Re-run our custom task to retrieve the new information, and act upon differences (for example, use as condition for later tasks)
Both in our case and yours I guess that a method for retrieving/comparing with the "previous" version of an item would have been preferred, but I was stumped there; I couldn't find any relatively easy way to retrieve the previous change set for an item. If anyone has any good ideas there, I'd like to hear these as well :).
I would like to get the issue list from Bugzilla and JIRA for an open-source project. For each issue, I'd like to collect the corresponding compilation units(for java projects, class/or interfaces files), which may relate to the issue.
Any idea on implementing this feature would be appreciated.
Many thanks!
For JIRA, there are some solutions out there you could use out of the box. See the documentation to integrate with source control for JIRA how to do it. This only works for some source control systems, you should which ones are supported. This gives you a list of change sets (e.g. for Subversion) for each issue.
Another approach could be to do it on your own through an interface to the source control system yourself. The following prerequisits have to be in place:
Your developers have the tools to add the information which issue was worked on by which commit on a per commit base.
You have rules that changes to the sources should all the time being done only for one issue at one time.
You are able to parse the additional information you will get from your version control system e.g. by a script or a program.
For Subversion and JIRA, it could work like that:
Ensure that all commits are only done if the Subversion commit message contains at least one JIRA ticket number. You may even ensure that by a pre-commit hook
Learn how to get the following information from the subversion log
The ticket IDs (by parsing the message) for each change set
The files that had changes for each change set
Collect for each file all tickets.
Show them in a format you like.
I think that this is not too useful, because ticket per class is too fine grained. Perhaps you should have a mapping of the files to modules, sub-projects, ... and collect tickets for them.
All solutions will be different depending on your selection of tools. JIRA and Subversion are here just examples :-)
The best way is to first integrate your issue tracking system with your source control. That means that whenever a developer commits a new change, it determines the set of issues related to this change. This linkage is managed by your issue tracking system and it can show you all the source files, resource files, config files that have changed in the context of an issue.
This info, will be available through the api of that issue tracking system as well.
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
What would be the best method of automatically generating a Release Notes text file from a Team Foundation Server 2008 nightly build?
We created a TFS report that lists all Work Items associated with a specified Iteration (version). In addition we added a custom field to Work Items to indicate if we wanted the work item included in the release notes report. (Not all Work Items are appropriate for all clients/users.)
You could automate this process but you would need to specify the iteration in your build task. Or you could list every work item that has been completed as of a specific date.
I think the solutions here are describing "build notes". If you want that, you really need to checkout the TFS Community Build Manager. It has a feature to generate build notes in Word files by using the OpenXML. It's clicking the VSIX and you're done.
But imho, build notes are not release notes. Release notes provide a more customer friendly way of listing you changes. And you need to be able to specify what work items you want in the notes, and the ones you don't want your customer to see. So for that, I have created a custom Team Explorer add-in. And it does more or less what the build manager does as to generating the OpenXML Word.
I use queries to define what the bugfixes are, what new features are available, ... and then the team explorer extension provides the GUI to specify the document fields (Title, descriptions, remarks, ...) and to select the queries corresponding to the blocks on the release notes. After filling in the details, the word document gets generated. I can provide with all the details if you want.
UPDATE:
I uploaded a sample xsl file for transforming the buildlog.xml to get an informative plain releasenotes.txt. Get it here: Automatically generate release notes textfile from Team Foundation Build
That one is actually pretty easy. Grant Holliday describes it on his blog. It basically goes something like this:
Install MSBuild Community Tasks (which contains the WebDownload Task)
Install MSXSL.exe from Microsoft (for transforming xml files)
Extend the tfsbuild project with information regarding the retrieval of the buildlog.xml (using WebDownload task) and transformation with MSXSL.exe
However, you need to download the MSBuild Community Tasks directly from tigris and not use the link provided in this blog post. This is due to the fact, that the link refers to the wrong version which does not support the UseDefaultCredentials options (that you need for the MSBuild Task to be able to connect to the proper TFS Webservice).
Here is the link to the article:
Building a release notes text file with team build
I got everything working except for the xsl file, because unfortunately, Grant does not offer a sample xsl. If you manage to create a proper xml transform file that fits your needs, it would be awesome if you can send me a copy. ;-)