My goal is to have the "latest version" of my code be that of an existing changeset. I choose Roll Back, and roll back to that specific changeset, but my code doesn't change to reflect the changeset's code. Additionally, I tried "Get Specific Version" for that particular changeset, and while my local code changes to the changeset's code, the column in TFS that says "Latest" shows "No" for those files that were reverted - see screenshot below. The screenshot below is a result of "Get Specific Version":
QUESTION: What's the difference between "Get Specific Version" and "Roll Back"? If my goal is to essentially change my current code base to the code base from an existing changeset, and have that as the "latest version" (for TFS reasons - I'm trying to deploy out to our web server using TFS, but since TFS "doesn't have the latest version" - see screenshot above, it uses the current, latest version which is not what I want it to use - I want it to deploy from the code base for the previous changeset), how can I do that?
If you "Get Specific Version" you are changing your local workspace version to that of a previous version on the server. This does not affect the latest version on the server. (You could, of course, check out that path and check it in, which would affect the latest version on the server.)
If you "Roll Back" you are changing the server version. Depending on how you perform this action, you may not be changing your local workspace version. If you do a "Get Latest Version", you will sync up to that latest version.
If you simply want to build/deploy an older version of the code the default build templates allow you to specify a changeset number (or date) and force it to use an older version of the code.
If you really do need to change the "current" code in TFS, then you can do rollback. But it sounds like your understanding of Rollback is incorrect. It's not "rollback to this changeset", rather it's "rollback the changes contained in this changeset".
So if your latest version is v9 and you want to go back to v5, you need to rollback changesets v6-9. You can highlight all 4 of these changesets and roll them back all in one operation. Then check-in.
This will give a better experience than trying to do a get on an older version then check-out/check-in. The history will more accurately reflect what you did, and the conflict resolution dialog won't try and do the wrong thing (as it would if you did a get then check-in/out).
Related
I am working in the enterprise on Visual Studio 2013 and Team Foundation Server. We have a test source and a production source, and I Get Latest on them both regularly. As there are only a few developers, we make changes directly in test, we don't have personal branches off of test (though when our shop was bigger, we did).
So I opened a file in Test, made a simple change to it, saved it, checked it into test, and published it to production. When I went to merge Test with production, I spawned a merge conflict. I am looking at the "server" version and the "local" version and neither one is correct. The "server" version is the file I edited, minus the edit I just made. That makes sense. But the "local" version is something I haven't seen before, what looks like perhaps an older version that I've never never worked on. Maybe this was my local copy and Get Latest didn't update it. But the local file I edited was exactly what I expected it to be.
So, what could cause that? How do I troubleshoot this problem? All I want is to get the correct version in TFS so it doesn't get blown away later, but I have no idea how to proceed.
This may due to when you do the get latest option, TFS didn't update the workspace correctly.
A clean way to do this, back up your file with changes, undo your pending changes. Delete the old workspace, create a new one. Get latest version from server for both test and production source.
Edit the specific file with changes, check it into the test, and finally do the merge Test with production again.
I was working on a project, and I didn't get the latest version before I submitted my changes, and someone had just submitted some updates to the project. I know I can go to history, right click on the version I want, and choose "Get This Version," but This doesn't let me choose between changes in the two versions. I usually have in the past just copied all of the code I want, but this is very tedious. I know I can click on the files it shows in Changeset Details, and it will show the difference in code, but there's no way to choose the code I want. What would be the best way to get the changes in code that I want?
When several people are working concurrently on a file, you may not be able to ensure that you're always working on the latest version. But you can check in your file no matter what has been modified by others. TFS will provides information and tool to help you resolve conflicts.
TFS will automaticlly compare your loacl verison with the latest version on server.You can choose which you want to keep.
By default, the window shows only the conflicts caused by the most recent operation you attempted. When the window is in this state, a message appears that begins: Path filter applied. To show all conflicts in your workspace, choose Get All Conflicts. A message that begins with: n Conflict(s) appears. You can also use Refresh, if new conflicts might have occurred. To get more information, reference https://msdn.microsoft.com/en-us/library/ms181432.aspx
I have a Visual Studio solution and am using TFS for version control.
When I've made a bunch of changes to my working copy of the solution, the Team Explorer window will show me all the files that I've changed, and allow me to compare my version with either the workspace (original) version, or the latest version in TFS.
However, before I check in my changes, I first want to integrate any changes that have been made (by other people) to the latest TFS version since I got the source from TFS.
I could do a Get Latest Version and hope for the best. However, I would generally prefer to know what will be changed, and have the opportunity to look in detail at those changes, before overwriting my local files.
Is there a way to either compare my workspace (original) version against the latest version in TFS, or to see what the effects of a "Get" will be before I actually execute it?
To be useful, this would have to be a at a solution level - I would not want to have to go through each individual file.
Use Compare... and select Latest Version. That's best executed from the commandline or the Source Control Explorer.
If you compare "Latest Version" (remote) with "Workspace version" (local), then it'll tell you what has changes on the server since the last get-latest.
If you compare "Latest version (remote) with "Latest version" (local), then it'll tell you what has changed both locally and remotely.
The command line is your friend you can use the /preview switch to see what will happen if you do the get
tf get $/MyTeamProject/MySourcePath /recursive /preview
In TFS I'm performing the following action.
UnShelve Pending Changes--> right click a file in a ShelveSet --> select Compare --> There are three choices:
With Unmodified Version
With Work-space version
With Latest version
What is the difference between 1 and 2 ?
Basically, the options are broken down as follows :
With Unmodified Version - The Shelve File will compare the files with any pending changes to the corresponding files prior to the shelve being created.
With Work-Space Version - Typically this will compare your current code running on your machine to the code at the time that you checked out the file. Basically allowing you to see what changes you have made in the current checkout.
With Latest Version - Compares your code to the most recent code that has been checked into TFS.
So the difference between the first and second options would be that with the Unmodified choice, you would be comparing with any changes that occurred prior to the shelve being created and your work-space choice would display the changes that you had made in the current checkout.
I am working on a project with another developer. We are in the process of a major upgrade with lots of breaking changes. The software we are working on is an AddOn to a product, and we are upgrading to work with a new version of the product. He has checked in some breaking changes that will not run in my environment yet because I am still running on the old version of the product. I have checked in some changes on top of those. Is there any way I can retrieve the code such that it includes only the changes up to the point before the breaking changes and also include only my changes after that in my workspace?
If I had not done a "get latest" I would be OK now because I made the changes on my machine so I would have them. But now I need to "get specific version" to take me back before all the breaking changes and somehow merge only my changesets into my workspace. But there seems to be no way to merge changesets into a workspace, only into another tree. I could select only the files that I touched and get the latest versions of those files, but some of the files contain changes from both my changesets and his changesets (and mine are after his).
So what I really want is a way to merge specific changesets into my workspace (without pciking up all the previous changes) to get back to the state I was in before I did "Get Latest". Is there any way to do that?
Looks like there's no good way to do this. Fortunately, I had another branch that represented the changes I wanted (I had only merged my changes I wanted into it). It didn't feel right to just copy the whole tree over my working tree, so I used WinMerge to identify the files that were different and copied just those files over (after a cursory look to confirm that it was a file that included my changes -- there were a few files generated by Visual Studio that were different just because they were in a different path).
So I guess the general solution would be to create a branch in TFS, merge everything you want into it, get a local copy, then copy the results into your workspace. That does leave a mess in TFS, though (how do you completely remove the dummy branch?) Fortunately the branch I had was one we really wanted to keep (we have a build branch separate from teh development branch).
I'm not really sure if this answers your question, but if you select "Get Specific Version..." then you can select a specific changeset.