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.

how is this related to entity framework? Seems like you have a general source control issue - but that has nothing to do with ADO.NET EF, I'd say... — marc_s, Sep 16 '09 at 18:05
I'd say it does, EF is at fault here for completely re-building the entire model file every time the smallest change is made. — mxmissile, Sep 16 '09 at 18:13
@mxmissile: ok, good point - that's one of the issues I don't like about EF myself. Looking into other ways of generating the necessary code files (e.g. one file per entity) using other means (like Code Generation) myself. — marc_s, Sep 16 '09 at 18:58
I'd say it's everything to do with EF. I have the same problem hence coming across this question. SVN works great for everything else we work with (even form designers most of the time) but fails in spectacular fashion with EF models. — nathanchere, Oct 18 '10 at 01:49

score 17 · Accepted Answer · edited May 03 '16 at 08:50

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.

the problem with this approach is that the `` node is repopulated every time anyone edits the diagram view. For larger teams or teams with a high turnover of contractors, it's difficult to manage the prevention of this. I'm wondering if you have had any success using `Git-Hooks` or similar to ensure that the tag is automatically cleared every time code is committed? Any pointers here would be appreciated. — Adam, Jun 10 '14 at 13:48
@Adam: See my update above. As of Entity Framework 5, this becomes less of an issue. — Scott Munro, Jun 12 '14 at 12:26

score 5 · Answer 2 · answered Sep 17 '09 at 13:52

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.

Wow, I can't believe that is the EF team's response to scalability. Just wow. Thanks for that link (+1)! — Michael Maddox, Sep 18 '09 at 08:10
Michael, that article was written for v1. The v4 features are still a work in progress. — Craig Stuntz, Sep 18 '09 at 12:11

score 3 · Answer 3 · answered Sep 16 '09 at 18:21

3

As you said, one option is locking the file.

Another possible option is to route all model changes through one individual on the team.

Another option is to break the file apart into smaller files (like one per class), possibly leaving behind some designer support in the process.

Another option is to create your own process, potentially using XSLT to transform the EDMX file, but I'm not sure exactly what this would look like, the designer.cs file is the massive difficult to merge one.

Another option is to consider a different ORM.

I'm not sure if they are doing anything to improve this in the next version of EF. Throwing that much data in a single file doesn't imply scalability of any kind (Yet LinqToSql does the same thing - In that case Damien Guard created some T4 templates to break the file apart, not sure if something similar exists for EF).

answered Sep 16 '09 at 18:21

Michael Maddox

12,331
5
38
40

maybe just a different approach to generating the code classes for EF will do (instead of throwing out EF all together). I know CodeSmith Tools are working on an EF version of the PLINQO (http://www.plinqo.com) code generation templates... – marc_s Sep 16 '09 at 18:59
Unfortunately, commerical tools like CodeSmith aren't always an option, but yes, there are some commercial tools out there that may help with this problem. Some of those tools may maintain compatibility with the EF designer, while others probably won't. – Michael Maddox Sep 16 '09 at 19:17
Although team size / available resources are always a factor, I agree with the idae of only one individual being assigned to change the entity model. Even when you aren't using Entity Framework, there should never be a free-for-all with anything related to a database schema or the objects that wrap around it. – nathanchere Oct 18 '10 at 01:51

score 1 · Answer 4 · answered Apr 20 '12 at 15:19

I actually tried to convince my company to go to Code First for this very reason, and was shut down, unfortunately. They like being able to use the designer. Unfortunately, I ran in to issues on our last production deploy where one of our WCF services has about 10 end points in it to support multiple consumers, and in the process of merging, there were several duplicated entries in the C-S section of the EDMX file.

In my personal projects, I'm using Code First exclusively. To me, it's the same reason I prefer manual over automatic transmission. Sure, the model designer may be easier (sometimes, as we've discussed), but with Code First, you get much more direct control of what's going on. Just like a manual transmission. :)

score 1 · Answer 5 · edited May 03 '16 at 08:54

I'm not super familiar with EF in particular, but I've had my fair share of issues with ultra verbose & fragile autogenerated code. In each case, the best answer on how to merge it was "don't." In your scenario that probably means one of two things:

1) Tighten your code promotion model so that EF code only flows in one direction. In other words, every conflict will be resolved as either "copy from source branch" (AcceptTheirs) or "keep target unchanged" (AcceptYours), and everyone should know which is which in advance. Most commonly, you'll want to AcceptTheirs when promoting newly tested code toward the stable nodes of the branch tree and AcceptYours when merging fixes back to unstable/development branches. (If there is >1 development branch then you'll want to partition things so that only EF code owned by the team working in a given branch follows the latter rule. Anything they're not intentionally altering should be overwritten by other teams' code flowing from the integration branch, using AcceptTheirs if necessary.)

               /- [...]
               /- v1.1
          /- Release

    + Integration
          - Dev1
          - Dev2
          - [...]

"Merge down, copy up"

2) Literally do not merge them; exclude EF code from the process entirely. When integrating branches requires changes to the database and/or ORM, regenerate the proxy classes directly from the database. (after resolving + building any conflicting changes to your SQL files, of course) Extreme version: do this during every automated build, not just when merging.

Entity Framework Merge Nightmare

5 Answers5

Linked