I am looking for a way to discard some unwanted change sets using TFS. I have looked into this site and many other and know that we need to use
tf merge /version:C137~C137 branch1 branch2 /recursive
However, I store all my source code in TFS DEV environment, I normally check out the code from DEV to my machine, work on it then check it back in DEV, roll back, fix it then check it back in. This process create many different change sets that hang around and needed to be cleaned up. So when I use TF merge command which branch I have to specify DEV and ????.
Thanks for your help
The merge command applies changes from one branch into another. /discard option means does not perform the merge operation, but updates the merge history to track that the merge occurred. This discards a changeset from being used for a particular merge.
But according to your description, you don't use branches or merge. What you want is delete/destroy changesets. Unfortunately, you can't delete changesets in TFS by default, if you delete changesets, the version control may be defeated.
You can always work with the latest version, when you want to work on a specific version, you can use TF rollback command. This command does not remove the changesets from an item's version history. Instead, this command creates in your workspace a set of pending changes that negate the effects of the changesets that you specify.
Related
We had some changes committed (let's call it changeset1) in what we call the Dev branch of our project that really should've been done in a new branch. So what I did to fix it is create a new branch off of the Dev branch (let's call it Dev2). Then I rolled back the Dev branch to before changeset1. So now the code base looks like the development was done in Dev2 and Dev was never touched.
Later, I then did some development in Dev, merged it to Stage, and then Prod. Now I'm trying to also merge those changes into Dev2 but when I perform the merge (in VS 2017) it auto-merges everything and it wants to delete all of the changes from changeset1. I guess because I rolled back Dev after changeset1, it sees that as the latest change and wants to merge that rollback to Dev2. How can I get it to see Dev2 as the latest and merge my new Dev changes into it without deleting changeset1's changes?
For clarification, Dev is the parent of both the Stage and Dev2 branches.
According to your description, seems the merge process didn't pick up the rollback changeset1 in Dev branch, which cause this scenario.
This is caused you didn't use /keepmergehistory option during your rollback.
tf rollback /keepmergehistory
This option has an effect only if one or more of the changesets that
you are rolling back include a branch or merge change. Specify this
option if you want future merges between the same source and the same
target to exclude the changes that you are rolling back.
Please go through the detail explanation and some examples in our official tutorial here: Example: /keepmergehistory Option
Besides, you could also take a look at this similar question: TFS merge doesn't pick up rollback changeset(s)
I figured out a way to resolve it. So to re-iterate, I think the problem was the changes I wanted were in Dev2, but I rolled back Dev after creating Dev2 so the rollback was the most recent change so the merge wanted to keep the rollback and delete the changes I wanted to keep from Dev2. So I came to the conclusion that what I need to do was somehow apply those changes to Dev2 again as if they were a new edit.
So what I did is:
Move the changes from changeset1 into a Shelveset
Merge Dev to Dev2, thereby deleting the desired changes
Unshelve the changeset1 Shelveset to Dev2
#1 was the hardest part. First I created two new workspaces: DevC0 and DevC1. I pulled the changeset from before changeset1 into DevC0 and pulled changeset1 into DevC1. So now DevC1 has all the changes I'm interested in and DevC0 does not. I then copied all of the changed files (using BeyondCompare but I think you could just copy all your files except for the TFS folders/files too) from DevC1 to DevC0. Then at the command line, I did a tf vc reconcile on the DevC0 folder to allow it to recognize all the changes I just copied over. E.G. (I didn't actually want /deletes in my case):
tf vc /reconcile /promote /adds /deletes /diff /recursive [DevC0 itemspec]
(Make sure your command prompt's working directory is a directory mapped to your target workspace). After that, all of the differences now appear as pending changes in Visual Studio Team Explorer/Source Control Explorer. So from there I can create a Shelveset.
#2 was just a typical merge from Dev to Dev2. It deleted all of the changes and made Dev2 match Dev. I don't know if I needed to check this in before applying the Shelveset but I did.
#3 My changeset1 changes are in my Shelveset, but the Shelveset belongs to the Dev branch. Luckily, Team Foundation Power Tools can unshelve a Shelveset to a different branch. E.G:
tfpt unshelve /migrate /source:"[Dev server path]" /target:"[Dev2 server path]"
This opened a window with merge options for each file. I manually reviewed the first few then tried auto-merging all. That did the equivalent of what merging via Visual Studio does - it auto merged where possible and left the conflicts up to me in that same window. After that, it appeared all of the desired changes were now pending changes in Dev2 and I checked them in.
I then tried a merge from Dev2 back to Dev just to see if it was going to behave correctly and it did merge all of the changes to Dev and marked many of the changes that were deleted by the original rollback as undeleted. For now, I undid pending changes from that merge until we are actually ready to merge this sub-branch of work into our main Dev branch.
I have made some changes in a branch which involve renaming the sub-dir a project's code files live in, and committed this branch. I was unaware that while I was working on my branch, another developer made changes to one of the source files in this sub-directory and committed this.
When I merged my branch, it didn't detect the other developer's changes and undid them silently, which we only found later. When I try to re-apply their changeset, it just restores the files in their previous location.
I can manually re-apply their changes since it's an isolated case, but is there actually a way I can apply a changeset in this scenario, tell TFS the two directories are equivalent or something?
In your scenario, you can use tf merge command from command line with /recursive keyword, as since there is no way to specify the old name of the source branch from the UI, but we can from the TF merge command line.
I have following situation:
I have created some new projects in solution in one development branch in TFS
I'm now merging them into the main branch.
Architect has idea to merge two new modules into one.
I have moved the code files
Project files has already been changed within the merge.
These files have pending changes in form merge, branch, edit. I wan't to make this file merge, branch, delete but TFS won't do that because the file has pending changes. Is it possible to force the deletion or undo edit without undoing merge, branch?
I don't want to try the merge again and combine files from two shelvesets... Is there any possibility to modify the status of pending changes?
No, TFS does not support that.
You could "undo" the file and just pend a delete instead.
As best practice you shouldn't be making changes as part of a merge, you should just do the minimum possible to resolve the conflicts and get it to build (or not even that sometimes) and then make your required changes in a subsequent check-in. This makes it easier to see in the version control history what changes were made when - I very rarely look to see if a merge of a change is any different from a prior edit.
So I fixed a bug on our main branch some months back, let's say some old changeset 555. Recently, I manually copied these changes to a child branch for a recently approved hotfix, changeset 999. I would like to do a Track Changeset on 999 and see this it has been merged to main as 555. But, I've done this backwards according to the TFS rules, you can't merge down to a child branch.
Is there a way to tell TFS "accept my old changeset 555 as the merge of 999 to the main branch"?
This is analogous to the ClearCase version tree workflow, using the "don't perform merge, just draw arrow". Thus the Track Changeset for either 555 or 999 would show that they are related.
I'm not sure what you mean by
But, I've done this backwards according to the TFS rules, you can't merge down to a child branch.
There shouldn't be anything preventing you merging this change to a child branch, you might have some merge conflicts to resolve. However if that really isn't a possibility and you want to merge "999" in to the main branch without actually merging the code (i.e. adjust the merge history) then you can using the tf merge command line.
Open a visual studio command prompt and use the command
tf merge $/TeamProject/childBranch $/TeamProject/MainBranch /version:C999~C999 /recursive /discard
This will tell TFS to update its history to say that the merge occured even though it hasn't. You might want to use the /preview switch before you do the merge "for real" to make sure you are discarding the files you expect.
I followed these steps:
Created a new development branch from our Mainline branch using a changeset from last Friday. There have been other changes checked in since then that I now don't want.
Made a change to the development branch.
Now, I want to overwrite the Mainline branch with the contents of the development branch, so I tried this:
s:\AllTfs>tf merge /recursive /force /version:T "$/Development" "$/Mainline"
When the merge asks me to resolve conflicts, I picked Take Source for all of them.
The resulting changeset doesn't seem to be what I want. I can't work out what it thinks it's doing, but if I look at files I expect to be rolled back and do diffs, there are no changes for them they just show up with Change types of 'merge'.
How can I achieve what I want... effectively replace Mainline with how it was on Friday with one additional change?
Proceeding with /baseless is one option for you.Another one, which I would have picked, is to rollback all checkins that were apparently of no use at all.With installed TFS Power tools navigate to "File >> Source Control >> Rollback" and simply pick the range of bad checkins and roll them back:
This would spare you the trouble of constructing the branch + having to rely on the \baseless option to get the job done.
Ok, when I added the /baseless option, I seemed to be able to get the correct changes pended.