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.
Related
Maybe its a confusing title but the scenario is this one - we have two branches; DEV -> QA. When tests are done people merge their changesets from DEV into QA one by one. All fine. The strange thing is that a small number of merged changesets are appearing in Merge wizard when we attempt to do reverse integration QA -> DEV. If I pick one for the merge, pending change shows that files are checked out with an 'merge,edit' tag but when compared to latest there are no differences.
Obviously we need to fix this since the list keeps getting longer and longer. But, I would like to understand why is this happening in the first place. Then, how to fix this situation.
We're using TFS 2015 server and Visual Studio 2015. No 3rd party tools.
Thank you for reading.
When you want to merge back, the changeset reappears is because when TFS does a merge, it bases the merge on prior merge history, not on the actual contents of the source and target files.
If you have such request, you can use tf merge /discard command to update the merge history, which does not perform the merge operation. This discards a changeset from being used for a particular merge.
https://learn.microsoft.com/en-us/azure/devops/repos/tfvc/merge-command?view=azure-devops
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 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.
We have a branch called "Main". In July 2012 I created a new branch from this called "Phase 3" for the next version of our project. We have been working on this since then, but from time to time some other changes get applied to Main.
In May this year we performed a merge from Main to Phase 3 with some of those changes, and that was all fine.
Between then and now, we upgraded our TFS server from 2008 to 2012 update 3. (I wasn't involved with the "upgrade" but I believe it was an install on a new server with some kind of backup/restore of the data.) We've bit had any other issues with this.
Last week I tried to perform another merge from Main to Phase 3. I chose "selected changesets" because we have done a serious amount of rework in our phase 3 branch so merging changes across is quite difficult - so I wanted to do them bit by bit.
However, I was surprised to see that Visual Studio was trying to merge across changes from July 2011 - a good year before the branch was made (the very first changes made to this part of our project in fact.)
Oddly enough, if I view the history of the phase 3 solution I can expand it and see all these changes. So TFS appears to know that they have already applied.
I tried to merge some of the earlier changes across to see what would happened. The only changes it included were to do with items that had been renamed or deleted. For example, we had renamed our solution so TFS wanted to branch and merge a copy of the SLN with the old name. Or we had some images that had been subsequently deleted in both branches, but not at the time of this new merge.
So I backed this out and tried to merge everything across from May this year - i.e. just before our last merge across. This carried over a hideous number of changes - all sorts of things including regular merge/edit type changes. So I backed that out too!
We had created another branch from Phase 3. I have been able to merge between the two branches OK. I think it was created about a week before the TFS upgrade. But it's not experiencing the issue.
We have other branches that were taken from Main. These are experiencing the issue in that TFS is wanting to apply changes that it has already made.
I am using VS2012 update 3 to do the merge. I also tried VS2010 just in case but that does the same. Also a colleague has tried it and confirmed the same symptoms.
I don't think it helps that our phase 3 is so vastly different to main that merging anything across is really difficult.
Does anyone know how I can best resolve this? I'm a little worried about doing something I might regret later on!
I encountered similar problems when upgrading from TFS 2008 to TFS 2010. The issue is probably due to partially merged changesets. I.e. some of the files in the changeset have been merged, some haven't. Or it could be a branch move / rename situation. See the answer here for details of why a branch rename can cause this problem
In TFS 2008 if you attempted a merge, then unchecked files from the pending changes list. TFS assumed that you didn't want to merge the file ever again and on subsequent merges you wouldn't see those files.
In TFS 2010 or higher, the behaviour changes. If you uncheck files from the pending changes, on the next merge TFS will attempt to merge those files again. I think TFS 201x has the correct behaviour but its a pain that MS didn't highlight the change in behavior.
To check if this is the case, run the following from the command line
tf merge $/tp/main $/tp/phase3 /recursive /candidate
The /candidate switch tells TFS to give you a list of changesets it wants to merge without performing the merge. If you see any changesets in the list that have a * next to them, these are partially merged.
To fix it you have 2 choices.
Merge the files and resolve the conflicts, it might be worth merging on a changeset by changeset basis rather than trying to do them all at once. This will probably be a bit painful but once it's done it's done.
If you're confident that the phase 3 branch is correct then you can Merge using the command prompt. If you use tf merge $/tp/main $/tp/phase3 /version:c123~c456 /recursive /discard where c123 represents the oldest changeset you want to ignore and c456 represents the most recent changeset you want to ignore. The /discard switch tells TFS to update the merge history so that it thinks the merge has been done, but it won't actually perform the merge. This should remove the partially merged changesets from your list of candidates
If you opt for option 2 then you should do some analysis to make sure that you really don't want to take the partially merged changesets.
If you get to the point where merging is too difficult, or you just don't trust it.. then the only practical option is the "stomp over it with a new changeset". ie - do the merge manually outside of TFS and then commit your new, fixed changeset. then, kill the old branch and start again.
Not an ideal situation to be in, but your source integrity is paramount. Hopefully starting from a fresh branch will prevent issues like this in the future.
I performed the following actions in TFS:
Accidentally made some changes to a bunch of files in the trunk
Realized it.
merged the changes to the intended branch
rolled back the changes in the trunk (using tfpt rollback)
later, during the regularly scheduled forward integration from the trunk, I undid the changes in the branch.
How can I reapply the changes? There are three changesets and about 80 files in question.
A couple ways to do this, but probably the quickest here would be:
Check out the affected files (for edit) in the branch.
Get Specific Version from trunk for those files.
Copy those files to the appropriate branch directory.
Check in.
You could also consider rolling back the rollback changeset in the trunk and redoing what you did (minus the undo).
What I ended up doing was a forced merge:
tf merge /r /force $/source/trunk $/source/branch1 /v:C123~125
I will watch this set of changes carefully when we reverse integrate back into the trunk.
I also tried a tricksy workflow of using tfpt to rollback, shelve, and unshelve /migrate. Unfortunately the conflict resolution dialogue in tfpt unshelve is a bit lacking - missing things like default buttons and stuff, so I had to mouse-click half a dozen times or so per file. So I decided after a few files to try something else first.