Entity Framework Merge Nightmare

Question

We've adopted the Entity Framework and we're finding that when multiple people make isolated changes in their individual source control branches, there are massive conflicts when they come together in a merge, resulting in broken model files.

We're leaning in the direction of forcing exclusive check outs on the file, but I'd like to avoid that.

My question is...

Is there a better compare tool that would handle this better, or is there another approach we could take?

Looking for something that is proven if possible.

NEW UPDATE: For those of you that come across this question, it is based on old EF. I suggest moving to using DbContext over EDMX. There is a lot of info here on SO about it. The simplicity of Database first or Code first far outweighs the loss of the designer in my opinion.

UPDATE: We resolved this issue by forcing exclusive changes to the file. By adding this process we completely eliminated any issues. While this was not the ideal solution, it was the most reliable and easiest to implement.

Answer 1

Craig Stuntz does a good job of explaining that it is the designer related xml (the positions of entities and associations etc on the design surface) that causes most of the problems here. Conflict resolution within the edmx:Runtime element however, is very achievable.

The best strategy for dealing with conflicts in the designer related xml is to bypass them altogether by sacrificing any custom layout and reverting to a default layout.

The trick is to remove all of the content of the <Diagrams> element. The designer will open without any problem and apply a default layout.

The following is an example of an EDMX file that will open with a default layout. Note that the content of the <edmx:Runtime> element was also removed however this was for brevities sake only - it is not a part of the solution.

<?xml version="1.0" encoding="utf-8"?> <edmx:Edmx Version="2.0" xmlns:edmx="http://schemas.microsoft.com/ado/2008/10/edmx">   <!-- EF Runtime content -->   <edmx:Runtime>   <!-- Removed for brevity's sake only!-->   </edmx:Runtime>   <!-- EF Designer content (DO NOT EDIT MANUALLY BELOW HERE) -->   <Designer xmlns="http://schemas.microsoft.com/ado/2008/10/edmx">     <Connection>       <DesignerInfoPropertySet>         <DesignerProperty Name="MetadataArtifactProcessing" Value="EmbedInOutputAssembly" />       </DesignerInfoPropertySet>     </Connection>     <Options>       <DesignerInfoPropertySet>         <DesignerProperty Name="ValidateOnBuild" Value="true" />         <DesignerProperty Name="EnablePluralization" Value="True" />         <DesignerProperty Name="IncludeForeignKeysInModel" Value="True" />       </DesignerInfoPropertySet>     </Options>     <!-- Diagram content (shape and connector positions) -->     <Diagrams>     </Diagrams>   </Designer> </edmx:Edmx> 

Note that the default layout that is applied here does not match the one that results when you select Diagram | Layout Diagram from the designer's context menu which is what I would have expected.

Update: As of Entity Framework 5, this gets a bit easier. The multiple diagram support added there offloads the diagram related xml to separate files. Note that I still had some old diagram related tags in an edmx file that had experienced a number of Entity Framework upgrades. I simply deleted the tag named Diagrams (including children) from the edmx file.

Answer 2

There are some strategies for dealing with large Entity Framework models in this article. You could consider using them. However, I have found that most of the pain with the regeneration of the EDMX comes from changes made via dragging and dropping on the GUI designer. On the other hand, doing Update Model From Database or via the properties window tends to make changes in a fairly sensible manner, and does not tend to be difficult to merge.

The biggest problem, as far as I can see, is that the layout information for the visual object model in the conceptual/mapping/storage models are in the same file. In other words, the problem is not so much the size of the file itself or the changes made to the entity model itself, but the wholesale rearrangement which happens when you drag and drop an object on the GUI designer. I wish the GUI designer layout and the conceptual/mapping/storage models were into different files. I believe this would eliminate most of the pain with merging changes to the model.

Therefore, we have a semi-official policy of not making changes to the graphical layout of the model. This is not much of a loss, because when you have more than a couple dozen entities in your model, the one-page-only GUI designer is not really useful anyway. And it certainly makes merges a lot easier.

Version 4 of the Entity Framework will have an option to do artifact generation based on T4 templates. I'm no expert, but it may be possible to coax the GUI layout information into a different file using a T4 template.