Here's our situation:
In TFS 2010 we have the main dev branch and a release branch.
At some point, it was decided that some code was in a poorly named directory so it was renamed in TFS (only on the main branch as it wasn't a bug fiw).
I have now fixed a bug in this moved code on the dev branch and want to merge the fix into the release branch.
However, when I do this, rather than performing a merge on the file, it creates a copy of the file in the new location and labels the change as 'merge, branch'.
Am I doing something wrong or is this a 'feature' of TFS?
Update: I've just revisited this post and retried. steps to reproduce the error are:
I have a file (control.cs) in Main/Desktop/UserControls and
Releases/V5/Desktop/UserControls.
Using source control explorer I 'Move' UserControls to UserControls2 and check in (I've also tried 'Rename' btw with the
same results)
I Edit control.cs on Main and check in.
I merge Main into Releases/V5 (Note I am merging on the whole branch, not just UserControls)
I now see the modified control.cs in Releases/V5/Desktop/UserControls2 and the old one in Releases/V5/Desktop/UserControls
I answered it earlier with the assumption that you have the DEV branch and I have more inputs after I did some more research in TFS with what you explained above.
This is what I did, I have a Source branch call it Main, I branched from Main called Release. In Main, I have two folders (f1 and F2), I renamed folder F2 to F3 and checked in the changes. Then edited the file File1 within F2 (now F3) and made some changes to the content, checked in the changes.
Now I merged the Main to Release and every changes were merged properly. In Release, the folder F2 was renamed to F3 and the file1 was merged to the right folder as well.
The change should show up as merge, rename for the folder and edit for the file.
Everything worked like a charm. I am using TFS2010 as well. Can you please let me know if you have done anything differently than what I just explained above? Am i missing something?
UPDATE:
I tested the exact scenario that you mentioned above and it merges the control.cs file properly even after the Move/Rename in the source branch. I believe that in your case - in the Release branch someone recreated (deleted and added again) the Usercontrols folder and/or the Usercontrol.cs file, so TFS doesnt recognize that its the same file/folder from the source branch and hence its not getting merged properly.
Can you check the history of the Usercontrol file in the release branch to confirm that?
Just adding some screenshots from my test:
Related
i am creating a private swift package for myself that I use in a different project.
For the package I have a develop, acceptance and master branch.
When I make a change in the project like a rename or a deletion of a file I merge this to the develop branch.
However when I later merge the develop branch to the acceptance branch or the acceptance branch to master branch I do not see this changes.
Instead the deleted files are back and the file I renamed also get back with the original file name.
I expect merge conflicts but those are not shown.
I checked the .gitignore to see if what gets ignored but I do not see anything that has to do with this.
I am not sure what I am doing wrong here or if it's simply not common for packages to work like this. Anyone got the same problem or tips on how to make it work better?
So Im trying to merge from branch A to B and after doing the merge, I check in the changes to B and then compare the branches again. There are still differences detected. One of which is a entity data model diagram "my_model.edmx.diagram".
Looking at the differences, its only seeing a difference in the location and width of the entity icons etc. This file is really just an xml file. There was also a .sql file also that didnt get merged and I managed to get it merged over by selecting it byitself, then merging just that file. The edmx.diagram file however, will not go over. Could it be an issue of file type?
Never heard this file type issue. If you can put the files into source control. Suppose these files must be supported by TFS.
A workaroud for this situation:
Clean the mapping folder for branch B(Make sure changes checked in)
and remove the mapping of branch B.
Remapping it to a clear local folder.
Merge branchA to B again, and check in the changes.
Update
Changes in each branch are independent from each other, so you don’t
have to check them in before switching from one branch to another.
Merging between sibling branches requires a baseless merging.
Source:https://msdn.microsoft.com/en-us/Library/vs/alm/code/overview (Capabilities→ Fundamentals → Branching )
I think you are using source control instead of Team Explorer. I had the same problem.
Asif
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).
having a weird problem with TFS (TFS2008). We've done a merge into our Main trunk. We've resolved the conflicts and we've checked in associating it with a single work item.
So we have our WorkItem with a single changeset in it.
Our build is failing because the previous version of the csproj file is being got from TFS. If I open the WorkItem and the go to links and open the changeset the csproj file is not listed. In fact no files that are "merge/edit" are listed... there are others missing the csproj is the first.
If I do a view history on said csproj file I see the last changeset it was in. If I open that changeset (same number as associated with the work item) the csproj file is there present and correct, along with all other "merge/edit" files.
If anyone has any ideas why this might happen and how to resolve it, it'd be much apreciated.
Thanks
If you do a view history on the MAIN trunk, and look at the changeset that you merged from your development branch, does the CSPROJ show there? It sounds like it may have not been picked up in the merge.
If it does show in that changeset, is there any chance that there was a conflict when you merged? If so, we've had the issue where the person doing the merging inadvertently chose to keep the target version. In that case, the conflict is resolved, and as far as TFS is concerned, there's no longer a need to merge that file.
If you have a list of the files that seem to be missing, and trying an additional merge isn't picking anything up, you can force the merge from the command line (something like):
TF.EXE merge /force /version:T "$/Project/Dev/Src/FileThatWasMissed.csproj" "$/Project/Main/Src/FileThatWasMIssed.csproj"
Of course, remember to change your filename and make sure you are in a mapped directory when you execute this command.
Our project has hit a point where we need to split off some code into a separate team foundation project. We would like to move these files so they retain their version control history. Temporarily we are copying the files back to the original team foundation project and re-adding them just so that our daily build & test process doesn't break. As we are able to modify our build & test process we will start to remove these temporary copies.
One issue we are noticing is that we have a nightly script that checks various maintenance branches to see if there are changesets that haven't been merged back to trunk. It is now whining about changesets that have been merged before. These changesets seem to be related to the files that have been moved and re-added. Any ideas as to why we are seeing this and how we can discard these merge candidates? If we do a merge /discard TF tells us "there are no changes to merge". It seems to be confused. Also are there other problems we might run into with this approach? Perhaps there is a better approach?
The solution that I found was to merge /discard all other changesets, then do a "catchup" merge /discard i.e. not specifying any version info. This generated a number of merge related pending changes but when I went to check them in, I got a TF14088 error. The workaround for this error was to checkin just the problematic files/folders first and then check in everything else.