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).
Related
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
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.
Our Visual Studio 2010 Solution includes six projects. One of the six is the main application and the remaining five are class libraries that are configured as Project References in the main application. Our TFS Source Control structure is as follows:
TeamProject\ClassLibries\Class1
TeamProject\ClassLibries\Class2
.
.
TeamProject\WindowsApps\Application1
I need to create a Branch of Application1 so I have this:
TeamProject\WindowsApps\Application1
TeamProject\WindowsApps\Application1-NewFeature
My question is, when I create the Branch for Application1, do I also need to create Branches for the five Project References whether they get updated with the new feature or not? If I do, do I need to manually update the Project References so Application1-NewFeature knows to reference Class1-NewFeature instead of just Class1? When I merge the new feature back into the main branch, do I need to update the Project References all over again? Branching is totally new to me and I'm afraid I'll have a mess of Branches and Project References that gets out of control. What is "Best Practice" for this scenario?
I find it best, in effect, to branch the entire solution or system of solutions. It doesn't duplicate files, so it's not a big deal to have projects in your branch that you're not going to change.
Ironically, one rule of thumb that I use is that anything referenced via project references should be branched together.
I am working with my co-worker on some files, that are in TFS repository. We have to share these files frequently, however, in the process of our development they are neither compilable, nor working properly. We don't want to put them in the repository, because the rest of the crew shall have problems with compiling the solution. However, the manual sharing would be rather painful. Is there a way to put files on TFS, but not inside repository? (mark as temporary, not finished or something like that).
You can use a shelveset - if you shelve your set of changes then your colleague can pick them up and the other members of the team will never see them. It is a bit of a PITA as you need to have 2 shelvesets (1 each as you can only update your own). The only other way is to branch and then merge when you have compilable code.
Another option is to branch the code into a new branch that the two of you use. When you are done working on the file, and it will no longer break the main build, you can then merge that file back down to the development branch.
When I merge files from one branch to another and then go to check in files into the target branch, there are MANY files checked out, just the ones that changed. For example, Main and Critical branches were the same and we made changes to only 2 or 3 files on the Critical Fix branch. I then merged Critical ==> Main, and when I went to check in changes to the Main branch I noticed that there were numerous files checked out, not just the 2 or 3 that were actually changed in the Critical Fix branch. Moreover, when I compare a file from the Main branch to one on the server, I am told that the files are identical. If the files are identical, why are they checked out? Any help would be appreciated, or even a link that explains how TFS 2010 does merges.
The default Source Control Merging tools in Visual Source Safe and then TFS have always been rather poor - they are often confused by the simplest changes, often detect identical files as being "changed", and the auto-merge facility frequenty fails (includes the wrong changes). I quickly learned distrust for these merge tools (in about 1995) and have not seen any evidence in any of the new releases since then that the core merge algorithms have been improved at all.
The good news is that you can replace the client-side merging tools with third party ones (I use one that works so well that I actually trust its auto-merge option. I once spent 2 days trying (and failing) to do a complex merge with the TFS tools and in the end bought this 3rd party tool and re-did the entire merge successfully in 15 minutes!)
The bad news is that the first step of branch merging just uses the TFS merge code, and so it gets confused a lot, resulting in the symptoms you've described. This is frustrating in such a key feature of such an expensive application as it wastes a lot of programmer time on every merge to fix imaginary "conflicts" - on the plus side, with the help of 3rd party tools it is usually very easy to reliably resolve these merge issues.
I have had the same problem. I created a branch of our DEV branch and made changes to a few files. I checked in my changes and merged the latest changes to DEV into my branch. After the merge all 30,000+ files in my branch were marked as changed. Just like cju, I found that a comparison of most of the files showed that no changes had been made.
I decided to undo all changes and try again. When I right-clicked on the solution and selected Undo, I got a message that one file had changes, was I sure I wanted to undo that file? I clicked "No to All" and when the undo operation was complete, only the files that had been changed during my merge from DEV were still checked out. This was exactly what I wanted so I checked those changes into my branch and continued working.
I hope others can correct their situation as easily as I was able to.
One thing I noticed is that when one file is changed in different branches resulting in exactly the same content, then merging marks it as a conflict since the file is changed in both places. Of course a difference view of the file notices that there are no changes and therefore an auto merge solves this automatically for you.