I just shelved some changes in TFS. It worked, because I saw the results in the output window. I immediately tried to find the new shelveset. From the Pending Changes window, I selected Find Shelvesets under Actions, and saw my correct username, but no shelvesets were found.
Help.
Sorry, but this is all I have to go on...
try doing this from the command line, just in case Visual Studio has got into a mess. Browse to a folder mapped in a local workspace first. The command should open a dialog that lists the possible shelvesets.
tf unshelve
My comment to my own question has the answer. It didn't create the shelveset because of errors. Duh!
I was a user of Mercurial for very long time and got very used to a hg incoming command. It shows what is the difference between my local Mercurial repository and remote server.
I was using it daily to check what others committed and together with tortoisehg I was able to quickly review commits of others.
Is there a similar command available in TFS?
One way of accomplishing this would be to find the latest changeset number in your local workspace first and then right click the branch to find it's history and associated changesets. If the local changeset and the last changeset in view history is same then you dont have anything to review or else you have changes to review.
To get the changeset number from your local workspace you can use the following command, as per this MSDN Buck Hodges: This should be run from the root of your workspace in the commandline.
tf history . /r /noprompt /stopafter:1 /version:W
You are also trying to follow the same process that you have been doing all along, have you tried exploring some of the code review functionality which TFS2012 gives? Check that out as well HERE.
Hope it helps!
Closest behavior to
hg incoming
is
tf history . /recursive /format:detailed /version:W~T
It shows a windowed (/format:detailed) list of changes from workspace version (W) until tip (T) on the server.
From a command line in your source folder use
tf get /preview
It will show what would occur if you did a get latest, effectively telling you what changes are incoming.
If you want the change set details as well, have a look at the answer to: Is there a way to find out which changesets I haven't synced to?
I have several projects on the go. So I download a copy of the code to a workspace, work on that and then shelve it for my manager and others to review with comments (this is done from within the MSVS2010 IDE's Pending Changes window/tab). Then when that is completed, I check in the changes.
Thing is, I would like not to have to load up the MSVS2010 environment every time I just have to do a check in. It's bulky and has a lot of windows popping up that I would like to avoid. So I would like to just execute a command line command to do the check in for me.
I tried tf checkin /shelveset:<name-of-shelveset> and I get this error:
TF204000: The Team Foundation server to which your team project is connected does not support the CheckInShelveset command.
Using tf checkin <path-to-workspace> worked but I don't have the shelveset comments.
Is there a way to get the comments populated with the shelveset comments I used last from within MSVS2010 without having to load it up?
I suggest you to add your profil as owner of shelveset, it's optional but important when shelveset can be created by lot of users
tf checkin /shelveset:<name-of-shelveset>;shelvesetowner
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 a developer and I've made some changes to a solution, which I have saved off to a shelveset. Another developer unshelves my changes and builds the solution on a server. Is there a way for the second developer to check in my shelveset? I know he/she can check in the individual files comprising the shelveset. However, I was thinking of a "checkin" command that took the name of a shelveset as a parameter, or if there was another way to check in those changes as a unit, with the shelveset name.
The other developer can open a Visual Studio Command Prompt and use the following command:
tf checkin /shelveset:shelvesetname;shelvesetowner
See Checkin Command on MSDN for more details.
I don't think check-in via TFS Command Line directly is a better way, it maybe conflict with the latest code on TFS.
I think the better way to check in shelveset if there are some another changes in you code, but you don't check in it, is create a new WorkSpace in your local computer
Then map the latest code to the new workspace, then unshelve(download) the shelveset, resolve the conflict if necessary, then check in the code
For those having issues with the error:"Items cannot be specified with the /shelveset option.", try putting the user name in parenthesis as follows:
tf checkin /shelveset:shelvesetname;"shelvesetowner"
An easy way to do this is to define a new workspace and have the developer unshelve to that workspace. Then, all of the pending changes for that workspace correspond to the shelfset, and they can check in everything in the workspace.
The second developer can go to Team Explorer -> Builds and right click on the Build definition you are working with.
Select “Queue New Build…”
In the combobox “What do you want to build?”, select “Latest sources with shelveset”.
If you go to the button “…” you can select any shelveset from anyone.
Then check the box “Check in changes after successful build”.
A build runs with that shelveset, the shelveset is checked in when the build passes.