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?
Related
I have a bunch of files in the 'added' state across many folders that were accidentally deleted from the file system. How can I easily either undo them or convert all of them to a 'delete' status? I'd prefer not to have to manually undo each file one at a time.
What I've tried so far:
In the Pending Changes window, using the Undo command for each missing file is tedious. Since the window does not identify which files are missing, I have to compare this window to the file explorer and compare the contents of each folder.
The answers for this similar question don't apply to me because my files are in the 'added' state, so comparing my workspace to the server will not identify these missing files.
I've looked through the TFS Power Tools for something to identify missing files but haven't found anything that directly addresses missing files.
The tfpt online command doesn't address missing files in the 'added' state.
If I read you correctly, in this case your underlying file system and what TFS thinks is on your file system have gotten out of sync.
The best, easiest, way I know how to rectify this is to undo all your changes, then redo the adds, deletes, and edits that you actually require. I know that with many files this will be a pain, but let me reiterate: I mean the best, easiest way and not the fun, effortless way (which I don't think exists)!
Do a 'clean' in your project within Visual Studio, then delete any bin/ and obj/ folders in the source.
Then undo all changes for your project.
If you are using TFS < 2013, I would recommend the use of Team Foundation Power Tools online functionality. For instance:
cd \dev\path\to\project\root\
tfpt online /adds /diff /deletes /recursive .
Otherwise, if you are using TFS 2013, then you can use the built-in 'reconcile' functionality (cannot find a web URL for this, the 2010 docs are incorrect, use 'tf reconcile /?' for a description):
cd \dev\path\to\project\root\
tf reconcile /adds /deletes /diff /recursive /noignore /promote .
With TFS Power Tools installed, run this command from a VS command prompt in the appropriate folder:
tf reconcile /deletes /diff /recursive /noignore /promote
This will display a list of pending changes. The missing files will all be selected with a new status of 'delete'. Click Promote to save the change, then try again to check in.
This is a slight variation of d3r3kk's answer but without the /add flag which causes more files to be selected than necessary.
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.
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.
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.
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.