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?
Using tf.exe, the command line utility for TFS, I've automated the process of merging two branches using tf.exe in a batch file in simple steps:
TF Get... /Recursive
TF Merge... /Recursive
However, while checking in the changes, "TF Checkin" Dialog shows all the pending changes selected in the dialog whether using /Recursive or not.
What I want: To select only modified files in my selected folder instead of all the pending changes. Please note that this is a random thing, as I have 100's of files in my folders, so only files changed during Merge should be selected (definitely these would be modified ones).
Solution I expect: To create a separate Workspace for my automated merge process. This would isolate the checkin process and would select only the changes made through this Workspace.
Another Possibility: Is it possible to Checkin files in a specific folder and ignore rest of the pending changes?
Thankx
I'm not sure I understand your problem right, but it is indeed possible to checkin only files in a specific folder. To avoid checkin problems you should probably do a "resolve" first. For instance
tf.exe get /r c:\src\branch1\project1 c:\src\branch2\project1
tf.exe merge c:\src\branch1\project1 c:\src\branch2\project1 /r /noprompt
tf.exe resolve c:\src\branch2\project1 /r /auto:acceptTheirs /noprompt
tf.exe checkin c:\src\branch2\project1 /r /noprompt /override:"done by script"
You should always do a /noprompt when running tf.exe from a script/automation process. This is to avoid popups. In the resolve I put /auto:acceptTheirs which will take the changes from the source branch when a conflicting change occurs. There are several different options here, you will have to concider which suits your purpose. /override on the checkin will override any checkin policies, which is probably (but not necessarily) a good idea from a script.
The approach with creating new workspaces every time is something I would try to avoid if possible. Creating and deleting a workspace is a heavy process, and in my experience it is difficult to keep track of all the workspaces so I usually end up with lots and lots of unused workspaces that needs to be removed.
Just discovered that we can also use Repository Address instead of hard-coding paths:
tf checkin $/MainRep/Playground/MyFolder/HTMLLogViewer /r
Would give same facility and would prevent us from using hard coded paths.
We are just in the process of migrating our TFS repo to Mercurial as we've had enough of TFS. Unfortunately TFS has thrown us one last curve ball before it lets us go. We've wrote a script that we intend to have "get" each changeset (including timestamp, check-in comment etc) and then add them to the Mercurial repo and check it in.
Unfortunately TFS is acting very strange when we execute the tf get * /version:C111 /overwrite command. It immediately returns "All files are up to date." But this is impossible. The workspace folder is empty! And viewing the details for the 111 changeset quite clearly shows that the changeset contains "stuff" i.e. the repo is certainly not empty.
What could be causing this?
TF will return "All files are up to date" if the itemspec you pass in is not found. If you don't include an absolute path, a relative path is assumed.
For example if you send
tf get myFile.cs /version:1009 /force
it looks in the current directory for myFile.cs, which doesn't exist, so it returns "All files are up to date." What we really want is
tf get C:\myproject\myFile.cs /version:1009 /force
Same thing with wildcards, eg
tf get D:\project\* /version:C111 /overwrite
Check out the itemspec link for more info.
You should try /all instead of /overwrite, this will force it to get all files, not just the ones it remembers getting to this workspace on the previous get.
MSDN Reference for Get
Instead of "Get latest version", you can "Get specific version" of type "Latest version" and check the "Overwrite all files even if the local version matches the specified version" checkbox. That will force a get latest.
I've had this same issue before, and after pulling my hair out, the only thing that corrected it for us was to un-map the workspace, delete all the local files, and then remap the workspace to disk - TFS would finally get a fresh copy of the files then.
We were using TFS 2005, for what it's worth - I'd be sad to hear that this situation still arises with newer versions. If you find another solution, please post it here, as I'd love to know how you resolved it.
I tried with /force, /recursive, /all options and still had the problem ("All files are up to date.") Eventually I realized the problem was due to mapping. So I deleted mapping and recreated.
My old mapping (incorrect) was done with a wildcard:
tf workfold $/* C:\DEV
So when I listed work folders (tf workspaces /format:detailed) it showed up like this:
Working folders:
$//*: C:\DEV
When I remapped as below, the get command started working:
tf workfold $/ C:\DEV
and the mapping was showing like this:
Working folders:
$/: C:\DEV
This can happen if you do not have adequate permissions to the source. I was able to see the entire source tree, all files, but I could not get the most recent version. I guess this is permission flexibility taken to the extreme (absurd?). To verify the issue was not workstation or mapping related, I tried looking at a code file on the team pages and received:
Image demonstrating lack of access to source file
I just had to fix this problem:
Get Tfs power tools. You can also get it from tools > Add-in manager inside visual studio.
It will require you to close visual studio to complete installation.
Once complete, open a command prompt in admin mode.
cd to your branch/solution directory.
run tfpt scorch (tfpt.exe comes with the power tools, if you don't see it, reinstall)
If it finds stuff missing, it will open up a dialog. Just hit next or ok and it will overwrite anything that does not match the server.
You can always add the "/force" parameter to TF GET to force it to get all files regardless of what it thinks you have in your local workspace (it maintains the versions of all of your workspace files on the server).
It looks like there are multiple ways to trigger this issue. In my case it was dealing with passing a relative path to a script that generated an absolute path and then passed that path to tf.exe. This is a Windows scripting problem more than anything else, but output from tf.exe is confusing.
Really what you'd like to see tfs return is "File not Found" instead of "All files are up to date".
In addition to the other suggestions made here, also double-check what you're passing to tf.exe by re-writing the command with echo first. If you're coming from a unix/linux background, string building just seems broken on win32.
broken.bat
SET PARAM1=%1
SET CMD_PATH="c:\path\to\%PARAM1%"
echo %CMD_PATH%
Result: broken.bat "tool.exe" => "c:\path\to\"tool.exe""
fixed.bat
SET PARAM1=%1
REM Strip quotes: http://www.dostips.com/DtTipsStringManipulation.php
for /f "useback tokens=*" %%x in ('%PARAM1%') do set PARAM1=%%~x
SET CMD_PATH="c:\path\to\%PARAM1%"
echo %CMD_PATH%
Result: fixed.bat "tool.exe" => "c:\path\to\tool.exe"
Check your workspace. I went to delete it as above (which probably would have fixed it as well) but I noticed that someone a project within my project got it's own workspace assigned in addition to the overall workspace. I removed that project from the workspace and it downloaded all my files when I clicked ok to exit the workspace menu.
My problem was that I was running VS developer command prompt from VS 2012 studio but my workspace mapping is inside vs 2013.
Make sure you run tf.exe from inside of visual studio directory which has workspace mapping, than simple tf.exe get "path" /all /recursive works just fine
Choose a date in future to get specific:
tf get * /version:D01/01/2099 /recursive /force /noprompt
Also make sure you have rights on the team project site in your project collections.
In my case, I could see the project folder and branches in TFS source control explorer, but I couldn't access the project's TFS website.
Instead of returning an error detailing a permissions issue, VS instead said all files are up to date when I tried to get the latest version.
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.
As TFS maintains an idea of the version that is downloaded on the client, such that "Get Latest" might not get the latest version; I was wondering if there was an easy way to report differences across an entire workspace?
I only ask as a member of my team is leaving immanently, and our IT department need to recycle his laptop very quickly, and I'm a little concerned that there is potential for some changes not to have been changed in.
Sorry misread the question.
If you have proper checkouts you can just do the following:
Go to the command line, and at the top if the workspace type
tf checkin . /recursive
This will present the what's outstanding in the workspace.
Or just shelve the lot to the serve and then you can peruse at leisure.
tf shelve
Oherwise the other thing I would do is
Just get the latest version of the software to another Directory and then use the excellent beyond compare tool from scootersoft to compare the directories recursively.
Once you have the files just copy the list to a bat file calling tf checkout on each one.
Then do tf shelve.