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 conflic

Answer 1

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.