Preventing EDMX Merge Conflicts and Cherry Picking Problems

Question

I use the Entity Framework as my ORM and I'm trying to figure out how to solve some major issues I'm running into. Let me describe my team's setup for some background.

We use SQL Server 2012 for our database, Visual Studio 2012 for our IDE, GIT for our source control and Entity Framework for our ORM. In our source control, we develop in a branch called "master". We have a "staging" branch (used for testing) and a "live" branch (this is production code). When we do a hotfix, we branch off the latest live code, push it to staging to test, then push it to live once it's authorized to go into production. After than is done, we merge the hotfix branch back into the master branch. We've also had situations where code that is currently in our master branch gets cherry picked into a hotfix branch and pushed live.

In all these cases our biggest pain point is the EDMX file. The thing is huge with hundreds of table and proc mappings. We are at a point now that we can only have one developer use the EDMX file at a time because GIT can't handle the merge conflicts. Also, the times we've tried cherry picking from our master branch into live, we end up with an EDMX merge nightmare.

We simply cannot continue this way and we certainly can't hire more programmers until we get our ORM under control. I'm at the point now where I'm considering using a new ORM like ORMlite just so I can get rid of the EDMX file. Does anyone have any experience with this type of issue? What can be done to prevent these merge conflicts and branching issues? I heard a rumor that in EF6 the EDMX file was going to be removed. Is this true?

Answer 1

We have had the same issue in our environment. One solution that looks promising is moving to Entity Framework Code First (in which you write the code, which generates your database schema) instead of using an EDMX file (in which the code is generated from the database schema). One big advantage is you have full control of the POCOs and don't end up with a bunch of messy generated code. Merging this is just like merging normal C# classes and doesn't cause the same headache that merging the EDMX does.

Here is a tool that will convert an existing EDMX implementation to code first: http://visualstudiogallery.msdn.microsoft.com/da740968-02f9-42a9-9ee4-1a9a06d896a2

Here is a good summary of the different approaches to EF, with advantages of each listed at the bottom: https://www.simple-talk.com/dotnet/.net-framework/different-approaches-of-entity-framework/

Update: Here is another technique that simplifies EDMX merge headaches: remove the <Diagrams> XML node contents. More detail here: http://blogs.teamb.com/craigstuntz/2010/02/03/38542