实体框架合并噩梦 [英] Entity Framework Merge Nightmare

问题描述

我们采用了实体框架，我们发现，当多个人在各个源代码控制分支中进行单独的更改时，当它们合并在一起时会产生大量冲突，从而导致模型文件损坏。

我们倾向于强制对档案进行排他性检查，但我想避免这种情况。

我的问题是...

有没有更好的比较工具来处理这个更好，还是有另一种方法可以采取？

寻找可以证明的东西。

新更新：
对于那些你遇到这个问题，它是基于旧的EF。我建议在EDMX上使用DbContext。在这里有很多关于它的信息。数据库首先或代码的简单性远远超过了我在设计师中的损失。

更新：
我们通过强制对文件进行独占更改来解决此问题。通过添加此过程，我们完全消除了任何问题。虽然这不是理想的解决方案，但它是最可靠和最简单的方法。

解决方案

Craig Stuntz 做了一个很好的解释这是设计师相关的xml（在设计表面上的实体和关联等的位置）的工作，这导致了大多数问题。但是， edmx：Runtime 元素中的冲突解决是非常可行的。

处理冲突的最佳策略设计师相关的xml是通过牺牲任何自定义布局并恢复为默认布局来完全绕过它们。

诀窍是删除所有的内容< Diagrams> 元素。设计师将打开没有任何问题并应用默认布局。

以下是将使用默认布局打开的EDMX文件的示例。请注意，< edmx：Runtime> 元素的内容也被删除，但这只是为了简洁起见 - 它不是解决方案的一部分。

 <？xml version =1.0encoding =utf-8？> 
< edmx：Edmx Version =2.0xmlns：edmx =http://schemas.microsoft.com/ado/2008/10/edmx> 
<！ -  EF运行时内容 - > 
< edmx：运行时> 
<！ - 为了简明起见，删除了 - > 
< / edmx：Runtime> 
<！ -  EF设计师内容（请勿手动编辑此处） - > 
< Designer xmlns =http://schemas.microsoft.com/ado/2008/10/edmx> 
< Connection> 
< DesignerInfoPropertySet> 
< DesignerProperty Name =MetadataArtifactProcessingValue =EmbedInOutputAssembly/> 
< / DesignerInfoPropertySet> 
< / Connection> 
<选项> 
< DesignerInfoPropertySet> 
< DesignerProperty Name =ValidateOnBuildValue =true/> 
< DesignerProperty Name =EnablePluralizationValue =True/> 
< DesignerProperty Name =IncludeForeignKeysInModelValue =True/> 
< / DesignerInfoPropertySet> 
< / Options> 
<！ - 图表内容（形状和连接器位置） - > 
< Diagrams> 
< / Diagrams> 
< / Designer> 
< / edmx：Edmx> 
  

请注意，这里应用的默认布局与选择 Diagram |

更新：截至实体框架5 ，这更容易一些。 多重图支持在那里添加卸载图相关的xml到单独的文件。请注意，在edmx文件中，我仍然有一些旧的图表相关标签，经历了许多实体框架升级。我简单地从edmx文件中删除名为Diagrams（包括子代）的标签。

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.

解决方案

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.

这篇关于实体框架合并噩梦的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！