I'm working with TFS 2008 with Continuous Build integration.
It's possible to have a list of files modified after Label applied?
Thanks a lot!
This is not as easy as you might thing. First off, don't consider the label to be a specific point in time. You can move a label from one version of a file to another, so the date of one given file might not be the same as the dates of the rest of the files in the build.
Instead, you probably want to go by a given date.
Get the start time of the build, then
Use the commandline TF.EXE to get the list (where the build start time is the datetime shown in version below).
tf history /server:http://tfs:8080 "$/Project/Dev/Src" /version:D2010-06-04T00:00~T /format:detailed /noprompt /recursive
This will get a detailed list of all changes that happened since 06/04/2010 at midnight, and the current time ("T").
If you're looking to do this programmatically, let me know and I can give some guidance there.
I've found that the history command will only tell you files that have changed between two labels, but won't tell you files that have been added or removed.
If you want to know that then you need to use the diff command, e.g.
tf.exe diff "$/<tfs folder>" /recursive /noprompt /format:basic /version:"Llabel1~Llabel2"
This is equivalent to doing the following from Visual Studio 2010
EDIT: I've recently re-tried this using TFS2013, and it now only shows changes to files that exist in both labels, i.e. is now the same as using history. So either I was wrong when I first posted this, or TF.exe has been changed.
Related
On one of our builds we are kicking off some automated process which is checking out and checking in some files automatically.
This all works rather well, but at this time we are running the checkin command which looks like the following
tf.exe checkin /force /comment:"foo" /noprompt /bypass /override:"bar"
All of the files with a Pending status will get checked in.
I'd like to make this script a bit more specific and only checkin the files (2 in total) which we actually change during the build, so we know for sure no files will get checked in 'by accident'.
I've already seen we can specify a single filename with the checkin command, but doing so we will get 2 different changesets in TFS, instead of 1. We would really like to have 1 changeset, containing both changed files as the changes belong to eachother.
Any ideas on how to approach this?
Minor addition / Short term solution
For the moment I've solved our 'problem' by specifying the folder where our modified files are located, which kind of looks like this
tf.exe checkin "/my/folder/location/" /recurse /force /comment:"foo" /noprompt /bypass /override:"bar"
Note the folder location and the /recurse parameter added.
You simply separate the files by spaces:
tf.exe checkin file1.ext file2.ext /force /Comment:"foo" /noprompt /bypass /override:"bar"
The documentation is not clear about this point but it might be a general specification of an itemspec that it can be multiple items.
See similar question about checkout: Is there a way to check-out multiple files from various folders in TFS in a single operation
As mentioned by others you might run into problems with the command line being longer than the system supports, in which case you might need to look at other solutions.
cmd.exe has a limit on how long a command can be. Using the version control API, or simply 'tf checkin /i' (no arguments) is likely to be a better choice than passing lots of long filenames.
It's normal if a file becomes automatically checked out due to a change, and if ultimately the contents of the file are changed back to it's original state. At that point you would see the message about identical contents upon comparison. You could also use tfpt uu /noget /r * command to ignore Files which are identical to the originals. You'll need to have TFS Power Tools installed for this to work. Note: there is no TFS Power tool 2017.
For more details please refer below two links:
Visual Studio TFS shows unchanged files in the list of pending changes
Can TFS Pending Changes show files that are truly changed like SourceGear Vault?
When I run tf diff, either recursively or against a shelveset, it goes through file-by-file and runs tf diff <myItemSpec>. I have my diff config set to compare files using windiff.exe which can handle a list of files, so running a new instance of windiff for every file is really annoying.
I remember being able to run windiff against an entire set of files at once years ago, but when I was working on that project, we were using two different versioning systems (originally our project was in TFS and we transitioned back to a proprietary versioning system, one that I'm certain had this functionality), so maybe TFS never could do this.
tf folderdiff seems like it should be the answer, but it doesn't appear that you can set the program it runs, nor can you specify a shelveset. It just runs some TF GUI which then allows you to run your configured diff program on a single file at a time.
Am I remembering wrong and TF never could do this? Is there there a hack/script that can do what I want it to?
As here, https://stackoverflow.com/a/2166188/616827,
tf diff $/Foo /version:C14317~C14318 /recursive /format:unified >
foo.diff
$/Foo specifies the entire repo (not one file at a time)
/Version to compare one changeset against the previous
/format is optional
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.
In TFS2010 each build is associated with a label by the build server.
Our SCM management wants to see all the changesets and related workitems between two labels. Mostly those labels are builds that have a build quality "Released". This way all changes between two delivered builds can be reported.
How is this done in TFS 2010 ?
I don't think you want to use the label, I think you want to use the date/time of the build(s). Labels are easily mutable and don't necessarily represent a point in time. Assuming you have the datetimes of the builds, you can use the TF.EXE command line to generate this.
For example:
tf.exe history /server:http://tfs:8080 "$/ProjectName/src" /version:D2010-09-12T11:30~D2010-09-29T11:30 /recursive /noprompt /brief
The /version: parameter is one of the keys here. This should be after the time of your first build and up to and including the time of the second build.
if you use /format:detailed, you'll get a listing of all files that changed in each of the changesets as well. This can be a lot of data. You'll probably want to redirect the output > output.txt if you do this.
UPDATE
As mentioned, you can, in fact, determine the changes between two labels. However, if these labels have moved, your results may be compromised.
tf.exe history /server:http://tfs:8080 "$/ProjectName/src" /version:LMain-CI_20100831.6~LMain-CI_20100927.1 /recursive /noprompt /brief
I would still recommend using the dates instead of the labels. I believe the results you receive from that approach probably more closely match your requirements.
UPDATE 2
I just noticed you're using TFS 2010. You will probably have to change the /server: parameter to point to the appropriate collection. Use TF.EXE history /? to get the list of parameters, but the change would be to use /collection:TeamProjectCollectionUrl
tf history /server:"http://tfsserver:8080/tfs/DefaultCollection" "$/project root/Dir/SubDir" /recursive /noprompt /format:detailed /version:"L1.1.66.0~L1.1.67.0"
Notice L prefix in version option.
We're using Team Foundation Server and we are using Labels to create points in our version history where specific versions (either internal or external) were produced.
Right now we were wondering if a particular changeset was done before or after a specific label (and thus included in that version or not), but we must be looking in the wrong place. This information is usually provided in the bug-tracking system but this time this field was left open so we thought we could use TFS to figure it out.
The version history for a file doesn't include labels applied. To find labels, the place I know to look is to use the "Get Specific Version" dialog, set type to Label and use the Label selection dialog to see which labels we've made, but this dialog doesn't tell me the changeset before/after the label was applied.
Is the only way to figure out if a particular change was part of that release or not to create a new workspace, map up the directory with the files to a temporary directory on disk, use the Get Specific Version dialog to extract that release and do a file-diff?
Please tell me how stupid I am and point me in the right direction.
Run in your local workspace
tf history . /stopafter:1 /noprompt /r /version:Lmylabel
to get
Changeset User Date Comment
--------- ------------- ---------- --------------------------------------------
88888 brian_low 11/11/2012 did some work
Have you tried opening Source Control Explorer, File -> Source Control -> Labels -> Find Label? [EDIT: that may have been in a beta version, and I don't have TFS here atm...]
Also, are you using SideKicks? The Labels SideKick allows you to find a label and see the related changesets.
A label in TFS does not represent a specific point in time - and a label can actually be edited after the event. See the following posts for more information:
Buck Hodges: Finding Changes between two labels in TFS VC
Brian Harry: Why TFS Label are not like VSS Labels.
For this reason, I tend to use Changesets in TFS when recording the point in time for a particular release (in fact we label our binaries and installers with the actual changeset number that they were built from just to make it easier to track). (A changeset does represent a unique point in time for the state of the repository).
Hope this helps,
Martin.
Faced this issue for the first time today. From now on I am including the changeset-number in the label-comment. Not very elegant workaround, but meets my needs.