I have a branch created some time ago in TFS of our main trunk branch. I've periodically been merging trunk->branch to keep it up to date and now I'm ready to push back to trunk.
I have modified about 10 files in 3 projects, however when doing the merge TFS marks 7000 files as modified, seemingly every file in the branch. I can see that the files are nor modified in every case I check but I don't dare check them in without checking every file and clearly that's no good in this case!
In the Source Control Explorer view, all these files and folders are marked as "merge" in the "Pending Change" column.
Can I fix things somehow or do I need to undo the merge and manually merge only the files I know I actually modified, breaking the whole point of merging?
Reasons for this might be one of the listed items in Why are all files marked with 'merge' in TFS?
But there are other cases as well:
Another branch of the target branch had itself a branch that was renamed then merged to the child branch then that child branch was merged to your target branch;
There was a move or rename of your branch and it was rolled back (but you can see it in the changesets still);
The way I solved it was to do a merge using the "Selected changesets" instead of "All changes up to a specific version". Then in the following dialog, exclude the renaming attempts.
Once this is done, you will still have these changesets in the history bugging you for every merge, so you might want to discard them with "tf merge /discard".
Related
One of my projects in TFS keeps displaying changesets as unmerged between the branches after I have already merged and committed them. I used the Track Changeset feature and clicked the Visualize button to see if the change was merged. It shows that it was merged but has a different background color and an asterisk. I checked the help and it gives this explanation:
If a branch has received some (but not all) of the changes in a changeset, the branch is filled with a pattern, and an asterisk follows the changeset numbers within that branch. For example, the previous illustration shows that only some of the changes in changeset 38 were merged to the Test branch
Track Changes Help
I don't understand how it is that I only partially merged those changesets. Perhaps I did not have latest when I completed the merge but it is happening to a lot of the changesets and this only happens on this one branched project folder.
Is there a way to find out what did not get merged and merge it so that the changesets will quit showing up as a merge candidate?
A partial merge is recorded when only some changes from a changeset are merged into the target. There are two common scenarios in below which you can end up with partial merges:
Scenario 1:Undo some pending changes when you are checking the merged files
In this case, even though we already merged changeset Dev to Main, it is still a merge candidate. This is caused by the fact that the merge engine detected that there are still some changes in that changeset which were not propagated from Dev to Main.
Scenario 2: Performed the merge at feature level not from the top of the branch
For example: consider that you have two branches Main and Dev, each of them has two folders (Feature1 and Feature2) and each feature folder contains one file. We edit both files from the feature folders (Dev\Feature1\feature1.txt and Dev\Feature2\feature2.txt) and check-in the changes.
If you perform the merge operation at the Feature1 level.（Changset142→
Changeset143） You will notice in the Pending Changes window that only the edit done in the Feature1 folder will be merged. Complete the merge.
If you take a look at the merge history of the Feature1 folder you will see that all changes from changeset 142 have been merged into changeset 143.
However,if you take a look at the merge history of Main you will see that only parts of changeset 142 have been merged into changeset 143. This is normal as changeset 142 has some changes – the edit of the file in the Feature2 folder – which were not delivered.
In case of a partial merge, to figure out what changes have been merged and what changes from the changeset were left out. The only way to achieve this is to diff the contents of the changeset that was partially merged, and the contents of the changeset that was generated as the result of the merge. More detail info you can refer this blog: Partial Merges in TFS – A Guide
Update
You can do a discard
merge.
This has to be done from the command line. Open up the Developer
command
prompt,
then navigate to a folder under either of your branches (i.e. navigate
to one of the affected
workspaces).
Then type:
tf merge /r /discard "$/Project/B1" "$/Project/B2" /v:C12345~C12345
This will take the changeset identified (in this case it was changeset
#12345), and update it as merged to the target branch (branch B2). The target files will be checked out, but they will not be changed - you
can simply check them in to complete the operation. After that the
changeset will no longer appear as a merge candidate. You can specify
a range of changesets to merge at the same time, but they should be
contiguous.
Note that after doing this a changeset will occasionally still show up
as a merge candidate - this is rather uncommon with the latest
versions of TFS, and it is virtually impossible to fix (unless you are
running your own local install of TFS and want to get your hands very
dirty in the database). If you end up with one of these marooned
changesets, just ignore it.
Source:
Finding merge candidates in TFS
We've had this happen more than a few times were we consider it to be more than a fluke at this point. When we are merging back after we are complete with our branch there are way more changes then their should be. So most of the files showing as pending changes never changed (in most of the cases in neither the branch or the base). When i compare them (i use beyond compare) there are no differences. I haven't went through all the files that didn't change but in most cases it seems like they are marked as [merge] and the files that actually changed are marked as [merge,edit].
In one case we probably changed around a 100 files it pending changes showed more than 22,000 changes. We tried checking them in at one point thinking tfs would be smart enough to know what files changed and which didn't. But it checked in all files. Does anyone know whats going on and how to fix it?
We are running TFS 2012 w\ Update1
Everyone is using Visual Studio 2012 w\ Update 1.
For anyone having the same issue a work around is to undo your pending changes. When you get the confirmation dialog choose "No to all". Only your pending changes should be left.
Regarding the problem where you had changed 100 files and TFS wanted to merge several thousand. This is usually caused by renaming (or deleting and then un-deleting, or moving) a branch. This has bitten me a couple of times and I feel your pain.
The best advise I can give is, once you've created a branch, leave it alone. Don't move it, don't rename it. If the location or name of the branch are wrong, live with it until it's time to delete the branch and create a new one.
Because of the way TFS 201x work behind the scenes, changing the root folder of a branch effectively turns it in to a different object. When you try to merge the branch again, TFS will perform a baseless merge which effectively means that it appears that all files in the branch have changed (even though they haven't) This is new behaviour, older versions of TFS (2005 / 2008) don't suffer from this problem.
e.g. you have a Team Project that looks like this
$/TeamProject/Main
You then create a branch from "Main" called "Dev"
$/TeamProject/Dev
You can merge as much as you like and there shouldn't be any problems. Then you decide that the folder structure might get a bit messy when you have several dev branches so you create a folder called "Development" at the root of the team project and move the dev branch in to this folder
$/TeamProject/Development/Dev
OK now behind the scenes the move is a rename and a delete, the old dev branch still exists under $/TeamProject/Dev (you can see this by going to "tools", "options", "Source Control", "Team Foundation Server" and then check the setting that says "show deleted items in Source Control"
The folder called $/TeamProject/Development/Dev is actually a brand new thing! Therefore it doesn't have a merge relationship with "Main". Confusingly though the IDE will show a relationship, but really it doesn't exist. The first time you merge from $/TeamProject/Development/Devto $/TeamProject/Main TFS will perform a sneaky baseless merge to establish the branching relationship.
The same thing happens if you rename a branch (the old branch will be deleted and a new branch will be created under the covers)
This Blog goes in to some more detail
The comment above with the "No to all" option in the undo confirmation dialog works okay, but as commented by Mark Hosang, this will not work right if you have new files. Mladen Mihajlovic is right that you can make sure to not select those new files. However with a large code base, wading through this is very tedious.
So my method: before getting to the confirmation dialog, you are presented with a window to select which files to undo. This window has sortable columns. You can sort by the Change column and select only the files with merge status (these are the unchanged files; merge, edit are edited files and merge, branch are new files). Just click Undo Changes with just those selected, and then enjoy the beauty of an uncluttered merge changeset.
Try this:
select all pending files
on context menu click 'Undo...'
in the 'Undo Pending Changes' dialog sort files by 'Change' column
deselect all files except 'merge' using shift+click
click button 'Undo Changes'
From my experience this happens when TFS has no relationship between file A in branch A and file B in branch B.
When merging branches TFS always creates a relationship between the files when no relationship is present already. Hence it wants to check in as "merge" to remember these relationships.
I tend to undo these "merge" changes when i don't need the relationships (e.g. for reparenting).
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.
I made a branch and the first time I went to merge from the source to the branch there were a whole bunch of old changesets coming up that it says were not merged but they were present well before the branch and I confirm that they were there.
Example:
Say I branched from Source to Target when there were 9 changesets in Source.
Change 10 was made in Source.
I go to merge from Source to Target and TFS tells me change 6 and 7 and 10 need to be merged (even though 6 and 7 were there before I branched and I can confirm those changes are in the Target)
I am new to TFS and this happened when I first started to implement Branching and Merging.
The newest branch I made did not do this.
Right now we have a Trunk and then 1 Branch for the ongoing QA for the next release and another Branch for the Hotfixes to Production. It was the QA branch that had this issue but when I made the hotfix branch it was fine.
I have come across this a few times. I eventually just merged the "rogue" candidate change-sets from source to target. I examined the pending merge and determined that there were no changes. Committing the merge got rid of these candidate change-sets. I figured that I could roll back if it didn't work out.
EDIT: It appears that if you upgraded to TFS 2010, there is a bug that will cause extra merge candidates (see http://support.microsoft.com/kb/2135068)
"Any items on a branch that have been renamed multiple times or have had multiple other items occupy their namespace (through add/delete combinations) will have lost their relationships with the corresponding items on other branches."
As for a resolution, the support article says:
"To resolve the issue with extra merge candidates, the /discard option should be used. To do this, run a merge of the following format from a command line:
tf merge <source branch> <target branch> /r /discard:CXXX~CYYY
In this example, XXX and YYY represent the changeset IDs of the range of changes to discard. After this merge has been checked in, the unwanted candidates will no longer appear for future merges. Also be aware that, because of improvements in the merge algorithm in TFS 2010, items deleted in both the source and target branches will result in changes to be merged. In those cases, it is best not to discard the changesets so that the merge history is updated correctly. "
I've had this a few times too. I suspect the cause is some funnyness in the way TFS manages pending merges. If you try to merge these changes, and the Change type is just "merge" and not "merge, edit", then it is safe to merge them and be confident that no changes have occurred. If you don't merge them, TFS will keep trying to merge the non-changes indefinitely, possibly obscuring real changes eventually. I advise merging these non-changes ASAP.
We just upgraded to TFS 2010. We created a development branch for each project. If changes are made in Branch1 and then Branch1 is merged back into the baseline, it merges every file instead of just the changed files.
Subsequent changes to files in Branch1 and then merging to the baseline result in only those changes being merged (which is what we want) unless changes from Branch2 were merged in between the first and second merge of Branch1, then every file merges again (which we don't want).
How can we make it so only changed files get merged everytime?
You can try to merge specific change sets instead of upto the latest change sets. That way you can even control which changes get merged into other branches instead of all changes being merged at the same time.
Also, when there are no changes, the automerge should take care of the files without creating any problems. What specific problems are you facing?
I believe the problem was that we had created the development branches, then deleted them, then recreated them. We ran into a problem similar to this in the past where a file was deleted, then a new file was added with the same name. The fix for the past problem was to do a baseless merge. Rather than go through that we decided to just delete the development branches and rebranch them with different names.