tfpt.exe is not exist anymore from VS 2017 and beyond. So how can I move files from one branch to another without checking them in. Say I've accidentally written code in the wrong branch or I'm told to move my change to a different version before checking in. This happens all the time. If there is not a way to do this, then either TFS is broken or I'm using it wrong.
This no longer works:
tfpt unshelve /migrate /source:"$/MyProject/DevCurrent/DevMain" /target:"$/MyProject/DevNext/DevMain" "Temp"
Please don't mark this question as duplicate without making sure it actually is. I've been researching this all day, and there have been 15 million different ways of doing this over the past ten years none of which work on modern tooling.
I need a solution for TFS 2018 and Visual Studio 2017. I do not have control over these versions.
After I had the same problem with VS2019, my best way to to it was to copy/paste the modified source folder to the branch target folder and use
tf reconcile /promote
to detect all added or changed files.
This happens all the time.
Why? it shouldn't happens all the time. check where you are and then start coding.
I've been researching this all day
So I guess you see this question, if the answers there not good for you, let me suggest a simple way to do that, but it's manual way and not just run a command:
1) You change a file and suddenly you put attention that you are in the wrong branch.
2) You don't want check-in the changes to the wrong branch.
3) In the past you put the file in Shelveset and then tfpt ..., but now the command no longer exist.
3) No problem. Go to your local folder, copy the file (with the changes).
4) Go to the correct branch local folder and paste the file there.
5) Go to Pending Changes and "Undo" the changes in the wrong branch.
6) Check in only the file in the correct branch.
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.
Yes this is one of the Doh! Damn! I shot myself in the foot. I don't have a lot of experience with TFS in large teams, but I'm facing this issue.
During a transition to new equipment, a developer forgot to check-in some code. Work proceeded on the new laptop for several weeks before noticing that the previous work was not checked in. Mutliple check-in have occured.
I have recovered the files from the old laptop, and have them on my current laptop. What is the best way to merge in these changes? Do I create a branch, merge in these changes, and then rejoin the branch?
Is there a "cookbook" out there that details what should happen when faced with various situations?
We are using TFS 2010.
Thanks in advance...
Creating a branch here is probably a little bit heavier-weight than what you need for this one-off situation. If it were me, I would do this:
Set up a workspace on your computer with the appropriate mappings.
Do a Get Specific Version to the version that the other computer was at. The best case scenario is if the user never deleted their workspace on the server. Then you can simply specify their workspace as the version and you'll get the files as they existed on the laptop. (You can specify this as Wworkspacename;owner name.) If the user deleted their workspace, you can get based on the changeset number they were at, or based on the date they were working at.
Copy the recovered files on top of the new TFS workspace.
Run tfpt online from the Team Foundation Server Power Tools. This will examine the local filesystem against the server and determine what changes were made. You may wish to examine the options, notably the /diff flags (which performs MD5s on the file instead of simply examining the readonly bit), and the /deletes and /adds flags, which detect deleted and add files, respectively.
Do a Get Latest on your workspace, resolve any conflicts, and check in.
You can follow this sequence to try out:
Make a merge-branch of your code version based on the time-stamp of where your restored laptop code has left the version control system.
Get your branched code to a location on disk.
Perform a check-out for edit of the entire workspace.
Copy the old restored code over the files in this workspace.
Perform a checkin of the local code into the branch.
Merge your latest code (main trunk) into the branch, merging changes, solving conflicts.
If all build and tests out correctly on the merge branch, merge that branch back into the main.
That should do the job.
Why Why WHY doesn't TFS's get latest work consistently?
You would have thought that feature would have been tested thoroughly.
What I have to do is, get specific version, then check both overwrite writetable files + overwrite all files.
Is my local setup messed up or you do this also?
TFS redefined what "Get Latest" does. In TFS terms, Get Latest means get the latest version of the files, but ignore the ones that the server thinks is already in your workspace. Which to me and just about everyone else on the planet is wrong.
See this link: http://blogs.microsoft.co.il/blogs/srlteam/archive/2009/04/13/how-get-latest-version-really-works.aspx
The only way to get it to do what you want is to Get Specific Version, then check both of the "Overwrite ..." boxes.
Sometimes Get specific version even checking both checkboxes won't get you the latest file. You've probably made a change to a file, and want to undo those changes by re-getting the latest version. Well... that's what Undo pending changes is for and not the purpose of Get specific version.
If in doubt:
undo pending check in on the file(s)
do a compare afterwards to make sure your file matches the expected version
run a recursive 'compare' on your whole project afterwards to see what else is different
keep an eye on pending changes window and sometimes you may need to check 'take server version' to resolve an incompatible pending change
And this one's my favorite that I just discovered :
keep an eye out in the the Output window for messages such as this :
Warning - Unable to refresh R:\TFS-PROJECTS\www.example.com\ExampleMVC\Example MVC\Example MVC.csproj because you have a pending edit.
This critical message appears in the output window. No other notifications!
Nothing in pending changes and no other dialog message telling you that the file you just requested explicitly was not retrieved! And yes - you resolve this by just running Undo pending changes and getting the file.
TFS, like some other source control providers, such as Perforce, do this, as the system knows what the last version you successfully got was, so get latest turns into "get changes since x". If you play by its rules and actually check things out before editing them, you don't confuse matters, and "get latest" really does as it says.
As you've seen, you can force it to reassess everything, which has a much greater bandwidth usage, but behaves closer to how SourceSafe used to.
It's hard to respond to a statement without examples of how it's not working, but it's crucial to understand that TFVC (in "Server Workspace" mode, which was the mechanism prior to TFS 2012) does not examine the state of your local filesystem. TFVC Server Workspaces are a "checkout-edit-checkin" type of system where this is by-design, an intentional decision made to massively reduce the amount of file I/O required to determine the state of your workspace. Instead, the workspace information is saved on the server.
This allows TFVC Server Workspaces to scale to very large codebases very efficiently. If you are in a multi-gigabyte code base (like Visual Studio or the Windows source tree) then your client does not need to scan your local filesystem, looking for files that may have changed, because the contract you have with TFS is that you will explicitly check a file out when you want to edit it.
You are expected to not mark a file as write-only and change it without explicitly checking it out first. If you go down this route, then the server does not know that you have made changes to your file, and performing a "Get Latest" operation will not update your local workspace, because you haven't told the server that you've made changes.
If you do subvert this mechanism then you can use the tfpt reconcile command to examine your local workspace for changes that you have made locally.
If you find yourself using "Get Specific Version" and selecting the "force" and "overwrite" options, then it is very likely that you are in the habit of bypassing all of the enforcements that TFS has implemented to keep you from hurting yourself, and you should probably consider TFVC Local Workspaces.
TFVC Local Workspaces provide an "edit-merge-commit" type of version control system, which means that you do not need to explicitly check files out before editing them and they are not read-only on-disk. Instead, you simply need to edit the file, and your client will scan the filesystem, notice the change, and present this as a pending change.
TFVC Local Workspaces are recommended for small projects that do not require fine-grained permissions control, since they present a much nicer workflow. You are not required to be online, and you do not have to explicitly check files out before editing them.
TFVC Local Workspaces are the default in TFS 2012, and if they are not enabled for you, then you should ask your server administrator. (Organizations with very large codebases or strict auditing requirements may disable TFVC Local Workspaces.)
Eric Sink's excellent book Version Control By Example outlines the differences between checkout-edit-checkin and edit-merge-commit systems and when one is more appropriate than the other.
The Professional Team Foundation Server 2013 book also provides excellent information about the differences between TFVC Server Workspaces and TFVC Local Workspaces. The MSDN documentation and blogs also provide detailed information:
Decide between using a local or a server workspace
Server workspaces vs. local workspaces
Team Foundation Server – Trying to understand Server versus Local Workspaces
Team Foundation Server (TFS) keeps track of its local copy in a hidden directory called $TF.When you issue the "get Latest Version", TFS looks into this folder and see weather I have the latest copy or not. If it does it will not download the latest copy. It does not matter if you have the original file or not. In fact you might have deleted the entire folder (as in my case) and TFS won't fetch the latest copy because it does not look into the actual file but the hidden directory where it records changes. The flaw with this design is, anything done outside the system will not be recorded in TFS. For example, you may go into Windows explorer, delete a folder or file and TFS wont recognize it. It will be totally blind. At least I would expect there Windows would not let you delete this file but it does!
One way to enforce the latest copy is to delete the hidden $TF folder manually. To do that, go to command prompt and navigate to the root folder where you project was checked out and issue this command
rd/s $tf // remove $TF folder and everything inside it
If you want to just check the hidden folder, you can do it using
dir /ah // display hidden files and folders
Note: If you do it, the tf will think you do not have any local copy even though you have it in files and it will sync up everything again.
Caution: Use this method at your own risk. Please do not use it on critical work.
"Get latest version" by default will only download the files that have changed on the server since the last time you ran "Get latest version". TFS keeps track of the files you download so it doesn't spend time downloading the same version of the files again. If you are modifying the files outside of Visual Studio, this can cause the consistency problems it sounds like you are seeing.
Unfortunately, there has to be one or more bugs in TFS 2008, since this problem regularly crop up on developer machines and build servers where I work as well.
I can do Get Latest, I can see in the history list of the project that there have been commits after I last did a Get Latest, I have not touched the files on disk in any way, but after the "Get Latest" function has completed, when I check the TFS tab, some of the files still says that they're not the latest version.
Obviously TFS is able to determine that I have old files locally, since the list says so. Yet, Get Latest fails to do that, get the latest version. If I do what you did, use the Get Specific version, and check the two checkboxes at the bottom of the dialog, then the files are retrieved.
We changed our build servers to always use the Get Specific version type of function instead, so this part now works, but since our build server (TeamCity) also relies on checking if there have been changes to the files in order to kick off a build, sometimes it lapses into a "nothing changed, nothing to see here, move along" mode and does nothing until we forcibly run the build configuration.
Note that I have experienced this problem on a machine that is never touched, except for get latest + build, both manually, so there's nothing tampering with the files. It's just TFS getting confused.
One time this cropped up I verified that the files on disk was indeed binary identical to the version previously retrieved, so no manual tampering had been done with the files.
Also, I fail to see how TFS can "know" whether files have changed on disk or not without actually looking at the contents. If one part of TFS can see that the files are indeed not the latest version, then the Get Latest version should absolutely be able to get the latest version. This in reference to comments to other answers here.
It might because you are login TFS as the same user, and the workspace name (based on machine name by default) is also the same, so TFS thinks your are on the same machine and same workspace, thus you already have the latest version of the files, so it wont get them for you.
try rename your machine, and create a new workspace as a new machine.
Go with right click: Advanced > Get Specific Version. Select "Letest Version" and now, important, mark two checks:
The checks are:
Overwrite writeable files that are not checked
Overwrite all files even if the local version matches the specified version
WHen I run into this problem with it not getting latest and version mismatches I first do a "Get Specific Version" set it to changeset and put in 1. This will then remove all the files from your local workspace (for that project, folder, file, etc) and it will also have TFS update so that it knows you now have NO VERSION DOWNLOADED. You can then do a "Get Latest" and viola, you will actually have the latest
I had the same issue with Visual Studio 2012. No matter what I did, it didn't get the code from TFS source control.
In my case, the cause was mappings a folder + subfolder from the source control separately but to the same tree in my local HD.
The solution was removing the subfolder mapping using the "manage workspaces" window.
Most of the issues I've seen with developers complaining that Get Latest doesn't do what they expect stem from the fact that they're performing a Get Latest from Solution Explorer rather than from Source Control Explorer. Solution Explorer only gets the files that are part of the solution and ignores anything that may be required by files within the solution, and therefore part of source control, whereas Source Control explorer compares your local workspace against the repository on the server to determine which files are needed.
It could happen when you use TFS from two different machines with the same account, if so you should compare to see changed files and check out them then get latest then undo pending changes to remove checkout
This worked for me:
1. Exit Visual Studio
2. Open a command window and navigate to the folder: "%localappdata%\Local\Microsoft\Team Foundation\"
3. Navigate to the sub folders for every version and delete the sub folder "cache" and its contents
4. Restart Visual Studio and connect to TFS.
5. Test the Get Latest Version.
In my case, Get specific version, even checking both check boxes and undoing all pending changes didn't work.
Checked the work spaces. Edit current workspace. Check all paths.
The solution path was incorrect and was pointing to a deleted folder.
Fixed the path and get latest worked fine.
Every time this happens to me (so far) is because I have local edits pending on the .csproj project file. That file seems to keep a list of all the files included in the project. Any new files added by somebody else are "not downloaded" because they are not in my locally edited (now stale) project file. To get all the files I first have to undo pending changes to the .csproj file first then "get all". I do not have to undo other changes I have made, but I may have to go back and include my new files again (and then the next guy gets the same problem when he tries to "get all"...)
It seems to me there is some fundamental kludginess when multiple people are adding new files at the same time.
(this is in .Net Framework projects, maybe the other frameworks like Core behave differently)
just want to add TFS MSBuild does not support special characters on folders i.e. "#"
i had experienced in the past where one of our project folders named as External#Project1
we created a TFS Build definition to run a custom msbuild file then the workspace folder is not getting any contents at the External#Project1 folder during workspace get latest. It seems that tfs get is failing but does not show any error.
after some trial and error and renaming the folder to _Project1. voila we got files on the the folder (_Project1).
Tool:
TFS Power Tools
Source:
http://dennymichael.net/2013/03/19/tfs-scorch/
Command:
tfpt scorch /recursive /deletes C:\LocationOfWorkspaceOrFolder
This will bring up a dialog box that will ask you to Delete or Download a list of files. Select or Unselect the files accordingly and press ok. Appearance in Grid (CheckBox, FileName, FileAction, FilePath)
Cause:
TFS will only compare against items in the workspace. If alterations were made outside of the workspace TFS will be unaware of them.
Hopefully someone finds this useful. I found this post after deleting a handful of folders in varying locations. Not remembering which folders I deleted excluded the usual Force Get/Replace option I would have used.
I encountered the same problem:
My development server was corrupted and restored, but the information restored was from a few days ago.
TFS was updated that all the files are up to date, but in practice my files were correct a few days ago!
Nothing I did helped. get latest did not get the latest version.
At the end I got specific varision from a month ago. my files were updated accordingly, and then I did get latest.
And it worked. the files have been updated.
Here's the part I get: When you shelve in TFS, it makes a server copy of the changes so they are not lost, but does not check them into the source code trunk/branch you are working on.
Question: Under what circumstances would you use the "unshelve" feature? Does it mean it will remove the shelveset from the TFS server? Can you do a get from a shelveset? Or is it really just a diff description between the shelveset and the "real" source code?
Unshelving is how you restore the shelveset to your machine so you can keep working on it. It doesn't change the shelveset on the server (to do that you need to shelve things again and use the same shelveset name).
One example for how I use it is to move changes between machines while I'm working on them. I'll shelve it on my desktop machine, then unshelve it on the laptop and then continue working on the laptop.
You can also use it to share changes with someone (for code reviews or other reasons). You shelve your changes, then the other person can go and unshelve it to see what you've done.
Unshelving doesn't actually change the shelveset or anything else on the server. It's just a get operation.
Herms is spot on. Read his answer.
One important caveat: if you've done a Get since the shelveset was created, Unshelve will only rollback the local version of files contained in the shelveset. Thus, it's quite likely you'll have an inconsistent workspace.
A good practice is to always re-run Get after you Unshelve. This ensures you don't waste time on phantom build errors that are actually just side effects of being in a half-new/half-old state. It will also require you to resolve any conflicts between the shelveset contents and the latest server revisions proactively, instead of only discovering them # Checkin time.
I use shelve to back up code-in-progress, just on the off chance my hard drive crashes or whatnot. I don't even have to worry about the code building, never mind working, since the work won't be seen by any other developers on my team (unless they go looking for it).
Unshelve pends the changes back in your workspace. Removing the shelveset from the server is a Delete.
Following on to what Richard Berg said, the power tools' version of unshelve actually includes a get and resolve.