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
Related
Another developer has some test files in a new directory in their branch. They're useful to me as well but I'm working in a totally independent, newer branch and he's not likely to merge his branch anytime soon.
I am able to branch his "test-data" directory into my branch but I really want to break the branch association so they're treated as new files in my branch, i.e. so TFS thinks our branches independently added the same new files and we resolve conflicts later since our test data is likely to diverge.
Is there a way to "orphan" the branched files somehow?
You can just get files in TFS using the web access component. Just browse to the folder through the code portion of web access and right click > get as zip.
You can do it from the command line as well but I am not familiar with that. SO has a lot of resources on how to do that from what I have seen.
It is possible to break the branching relationship in TFS and there are many questions on SO on how to do that. But your branch wouldn't initially treat them as 'added' and the history will be in TFS. I would recommend branching just the folder his useful code into your branch and leaving that relationship for posterities sake.
That being said, depending on your situation it may not make sense. If you want to remove the branching relationship immediately, then I don't think you need to use 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 some general purpose classes in one project that I would like to branch to another unrelated project in another TFS folder that I have mapped to a different workspace. I would prefer branching to plain copying to keep the change history and be able to merge back any changes.
However, when I try to branch the file in TFS, it complains that no appropriate mapping exists. Is there a way to branch across workspaces?
It turned out that I just had to select my source control explorer workspace to be the target workspace rather than the source workspace, then branching was allowed.
Now the files appear in the other project with history and possibility to merge back.
No, that's not possible - at least not that way.
But if you have general-purpose libraries, which are used across various applications, you should reorganize your project and workspace structure anyway...
If you had for example two solutions, which partially include the same project(s), and then would map each of these solutions to an individual workspace, then it should work.
HTH.
Thomas
I am merging my development branch into the main branch. There is only a subset of files that I have changed in my development branch, all other files should remain unchanged. Logically, I only want to merge files which I've changed. I would not check in a file which I did not change.
But when I do the merge operation in TFS, it marks every single file in the tree with change type 'merge'. It looks like I must checkin every single file in the whole source code tree! I really do not want to do this becasue then it becomes impossible to look at the changeset and see what files I acctually changed as part of my project.
At first, I thought I could use the tfpt.exe Undo Unchanged command to undo all the 'merge' changes, but this won't undo those changes.
Anyone have any ideas on this? thanks.
This also happens with a baseless merge. A baseless merge occurs when TFS doesn't have an existing merge relationship between the branches you're merging. As a result, it considers every file 'new' in both branches, so it 'merges' every file.
To create a merge relationship, so that future merges only list the files that you've actually changed, you need to do a baseless merge of all changes up to a specified version so that TFS knows what the common baseline should be. You should do this after merging these changes - it's too late to correct the baseline for this branch now.
If you don't actually want to take any changes from the other branch, but just tell TFS that these are logically at the same version, you can do a merge 'giving credit' for the changesets: tf merge /discard.
There are a number of possible reasons. This is not a complete list:
You performed a namespace operation (delete, undelete, rename) on a parent folder of the
files marked "merge"
You performed a namespace operation (delete, undelete, rename) that had already been performed in the target branch
You performed a sequence of namespace operations that collapsed into a no-op (eg delete + undelete, or rename a -> b -> a)
There are unresolved conflicts
You performing a discard
Note: all of these apply equally to 2005 & 2008.
In Visual Studio 2008 and TFS 2008, this does not occur. Only files that have changed will be marked as merge. If you do a compare of a file between the branch and the trunk are there any changes? Changes such as encoding will still make TFS merge this file back.
This question is a derivative of a previous question: How to version resources that are shared across projects
I have a project that contains code that is consumed by many other projects. Specifically, one folder in this parent project has been branched to dependent child projects.
We have since made changes in the parent project and checked them in. In Source Control Explorer, I right click on the branched folder in the parent project and select "Merge", intending to push the changes to a dependent project. I select the child project as a destination and then select "Latest Version". The wizard informs me "There are no changes to merge."
From my perspective, this isn't true, since the recently updated files are clearly different.
Is there a fundamental misunderstanding of the merge process in TFS here? What do I need to do differently?
The TFS merge engine relies almost entirely on history, not file contents. This makes it efficient for very large trees, and flexible for tasks like safely cherry-picking changes -- but it also makes answering your question difficult.
The first step is to understand the diagnostic commands tf history, tf merges, and tf merge /candidate. Here is a good introduction: http://blogs.msdn.com/dstfs/archive/2009/04/15/a-note-on-merging-and-the-use-of-tf-merges-tf-merge.aspx
If you are new to branching & merging in TFS then your history is probably not very complex. I think it's likely you'll find your answer with one quick call to tf merges. However, tracing merge history can become extremely convoluted in the general case, so if you have trouble feel free to post back with more details.
Go to one specific file you know has changed in your "parent" project. Try merging just that file. Don't check anything in; just see what happens.
Something to watch for: The merge tools will not include files that have been added after you branch. You have to branch new files explicitly before you can merge any further changes. If a file is added to both parent and child folders without using a branch operation, the merge tools don't treat them as versions of the same file (and you can't merge changes between them).