David Pallman gives 7 WCF and SOA tips. Not all rocket science but interesting non-theless.
Recently I was involved in a pretty large project to do a full and complete source code merge of 2 branches into one. We used TFS in the project and that was a first for me. So perhaps my experience was sub-optimal due to my lack of understanding of TFS but here are my thoughs on it anyway:
For some reason the branch relationships that should have existed between all the files of the two code branches were broken for some of the files. Even when we did a baseless Merge these relations remaind broken even though the manual says that they should be fixed after a baseless merge.
Using the Auto Merge “feature” reintroduced some defects that were fixed in one branch. Clearly this is not a “featue” you want to use all that often.
A Merge cannot cope with refactoring. Basically you are on your own when you refactor too much of you code and the text-based compare can’t match up the pieces of code that are the same, because they’re too far apart.
Merging of generated assets (workflow, dataset, etc.) is a disaster. You would normally just merge the model and let the tool generate the code for the new model. But manually (or automatically) merging the “model” is no easy task.
Resolving conflicts in project and solution files is also problematic. Most of the time we just made sure that all the changes of both branches were in the output and later sorted out the deleted files and stuff. Problem is that you cannot see the context of these files (associated files etc).
Resolving conflicts in normal source code (C# in this case) was not a walk in the park either. The 3-view comparer tool you’ll get to resolve these conflicts has no syntax collering. Its basically a scitzofranic notepad.
I think the problem with resolving conflicts is that it is a text-based operation (at least it seems to be). The auto-merge feature has no clue what it is merging and therefor it is no wonder it makes a mess of you source files. What you need is a specific conflict resolver for eacht type of file (with Text as the default fallback). So If I had a DataSet resolver it would know that this xml schema was in fact a DataSet and it could make (or propose) educated changes to the output. If you’d had these resolvers with builtin knowledge of what they are merging, I think the result would improve drastically. And it would make me a happy camper again. Up until that day, code merges are a pain for me.
What is your experience with merging code trees?