I have main and dev branches. I make changes in both and check in. I merge from main to dev and check in. Now I merge from dev to main. I have conflicts. How is this possible?
Resolving a conflict for a merge in one direction is not necessarily appropriate for a merge in another direction. In many workflows you're basically merging in order to keep two branches as similar as possible - for example, taking changes from a development branch into a production branch, and maybe moving critical bugfixes from the production branch back to a development branch. In this sort of workflow, you typically wouldn't want to diverge when merging two branches (you want that critical bugfix in both branches, after all) so it's not obvious why you would have to resolve the merge conflict both times, but that's certainly not the only workflow when working with branches.
I used to work on a Java project that had some utility libraries that we shared with a group working on a different project. At some point, our libraries needed to diverge from theirs for various reasons, so we took a branch of their project and both groups made unique changes to the library. Sometimes it happened that we would fix a bug and sometimes it would happen that they would add a new feature, so we frequently merged back and forth with each other.
You can see here that the results of merging from our branch to theirs should not necessarily be the results of merging from their branch to ours. Let's assume that there was a file where we added some new methods and maybe fixed a few bugs. And let's assume that they'd added a few different methods. When they merged our changes into their branch, they'd get a merge conflict and let's assume they took the bugfixes but did not take our new methods since they didn't need them. Now when we do a merge to get their changes into our branch, we still get a merge conflict - this allows us to take their methods into our file.
If TFS were to make some assumption about the merge from their branch into ours based on the results from our branch into theirs, it would be inaccurate.
Related
We have a main work branch that is a child of the Production branch. All work is done in the work branch (or below) and merged in to Production only when we release code. We recently found that there are changesets missing from our Production branch that should have been merged in months ago. But we've merged the work branch in to Production several times since then. I don't know how many changesets are missing, but we are about to have a release and I would like to use this chance to fix this.
Is there a way to overwrite a parent branch (similar to when you overwrite your local copy with latest from source)?
I know I can force changesets, but that requires knowing what changesets to force. Is there a way to identify differences in the changesets included in two branches?
My last resort is to nuke the parent branch and just create a new one, but that seems heavy handed and really isn't ideal.
I have a situation where we were working on feature branches against a main development branch ('trunk') and each release cycle, a release branch would be taken from the current development branch.
However, a release was cancelled very late on and instead we were asked to issue the previous release with only some features - after these were all integrated into the main dev branch.
So what happened was the previous release branch was taken as the base of the new mini-release, and we now have to re-apply specific changes that were already made against the development branch. I luckily still have my feature branch and it was never merged. It is based on the development branch, however my branch was taken fairly early on in the release cycle and was not updated by re-merging parent (trunk) changes - so my branch's parent is actually not too dissimilar from the new branch I need to apply it to.
I know TFS has some facilities for re-parenting and baseless merges but what is likely to work best? More importantly if I try re-parenting, can I break my branch or am I safe that I can try things, back them out and try again if there are problems?
My branch is fairly large, maybe 50 changesets applied to quite a few separate modules. I suppose I could try to apply each changeset one-by-one instead?
In my experience, baseless merges are always terrible. In most cases I find diffing and merging the two branches manually via a compare tool (like BeyondCompare) is easier and more reliable than using the TFS tooling.
That being said I would challenge you to consider going to a single main branch. We made the leap (a huge leap for us at the time) but it has paid dividends many times over at this point. The key is being Release Ready:
https://dotnetcatch.com/2016/02/16/are-you-release-ready/
I have the Development branch forked from the Main branch.
Could I merge the Development branch back to the Main so that Main branch code would be equal the Development branch?
What is the most safe and reliable solution for this?
The easiest way I've found to do this is to do a merge using Visual Studio and the Source Control Explorer.
In the Source Control Explorer, right-click on your development branch and select Branching and Merging > Merge
In the Target Branch drop-down select your trunk ("Main") as the destination. This is likely the default selection if you've branched from Main originally.
There are two options:
All changes up to a specific versions: You choose based on a revision and merge it all up to that revision in one fell swoop. If you have a lot of changes, this can save you some time, but also is riskier in terms of resolving conflicts if there have been a lot of changes in Main.
Selected changesets: You select single or groups of changesets to merge back and then repeat this process until you've merged back what you need. Less risky option, but much more time consuming. I personally prefer this approach so that I can see the changes going back into the trunk and know what to expect as changes.
TFS will instruct you if there are merge conflicts while you are merging. This occurs when you change something in the trunk after you've branched to your development. If one of the changes you've made in development conflict with the changes you've made in the trunk, you will have the chance to resolve this in Visual Studio.
If you do not have any conflicts, your development changes will move into the Trunk and simply merge with the changes you already have there.
I admit one work place they merged the Trunk to the Branches, but its not supposed to work that way.
The generally accepted method is merge the Branch back into the Trunk.
It sounds like you are working in the Trunk ("I can create some additional folder or additional files in the trunk") and wanting to merge into the Branch.
I recommend doing it the standard way: only work in Branches merging back to the Trunk, never coding directly in the Trunk.
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.
Simply put I have the following branch setup:
MAIN
|--- DEV
|--- PROD
Most developments are done in the DEV branch. When the code is ready to test, everything is merged to the MAIN branch and published to our test environment. When tests are completed, a merge to PROD is done and everything is published to the production server. Every now and then changes (mostly bugfixes) are made on the MAIN or PROD code, but this is an exception.
I have been asked to think out a system for feature and bugfix merging. This means that separate changes in the DEV should be merged across MAIN and PROD. With our current setup this information is lost: for example features A, B and C are implemented in the DEV branch. Let's say every feature has two corresponding changesets: A1, A2, B1, B2, C1, C2. With our current way of working, everything is merged to the MAIN branch in one go. So when we want to "cherry pick" features which have to go from MAIN to PROD we can't do this because there's only one changeset on MAIN: the checkin of the merge.
How would you fix this? Do I need to change something to my branching strategy?
I'm using TFS for source control.
So when we want to "cherry pick" features which have to go from MAIN to PROD we can't do this because there's only one changeset on MAIN: the checkin of the merge.
You can write a tool to piece through the merge history, if you like, but the real answer is don't do that. When you cherry pick, you lose any guarantee that the code you tested and stabilized in the source branch will perform the same way in the target branch. Sometimes that's ok, but in your case it defeats the whole purpose of having an intermediate branch sitting between raw untested Dev checkins and your live PROD deployments.
As discussed in my favorite branch/merge video, your guiding principle should be "merge down, copy up." That is, whenever the need arises to deconstruct and/or apply code diffs, let unstable branches take the hit. (Cherry picking features out of an otherwise integrated app is one example.) Meanwhile, code that's promoted up toward stable branches like Main & Prod should always be a straight copy that matches what you've already worked so hard to stabilize in the source branch. Sounds like you're following this strategy currently; preserving it in the face of cherry picks would be my #1 motivation for using feature branches, even moreso than insulating feature teams from each others' breakages.
Managing dependencies between features is an issue, as Jim mentioned. If you can identify them in advance, the usual solution is to make sub-branch(es) that are shared by the features with the common dependency.
Feature1
\
LibA---
/ \
Feature2 \
DEV -- MAIN -- PROD
Feature3 /
\ /
LibB---
/
Feature4
Software doesn't always go as planned, of course. And this doesn't work at all if the branches that need to share code are on opposite sides of the tree (e.g. if Feature1 depends on LibA and LibB, but Feature2 is ill equipped to be part of B for structural or technical reasons).
I don't think there's any magic sauce here, you've just got to find a system where you have a revision on main for each unit you might like to cherry pick.
This can be done trivially by merging each revision individually, which is a pain, but gets you what you want.
Alternatively, you can up the granularity, by merging each feature into main one at a time. This requires that you work sequentially on features, which may be ok if you're on your own, but will be a pain if there's a few of you, since you'll have to go through a code freeze where some people have finished and others haven't.
Another way of working which you may or may not find more manageable is to have a DEV branch for each feature. In this sense, instead of having an ever existant DEV branch, have a collection of ephemeral DEV branches that only exist until the feature is completed.
The reintegration of each DEV branch will give you a clear revision in main which can be cherry picked.
You can get dependencies between dev branches. Say branch devA needs some implementation from branch devB, you'll have to merge the required parts of devB into main and then merge them down into devA. However, devA shouldn't be needing unfinished work from devB, so you should (in theory) be able to RI those parts happily anyway. And of course, since you're cherry picking into PROD, these partial integrations don't have to get published.
Given your branching strategy, I guess you've already found this, but if not, it's worth reading:
http://branchingguidance.codeplex.com/wikipage?title=html&referringTitle=Home