Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,131 | Comments: 45,567

filter by tags archive

Reviewing the Entity Framework Source Control Support

time to read 3 min | 436 words

Frankly, I am quite amazed that I even need to write this post. Source Control is such a basic part of the development process that I didn't want to believe there could be anything to say about it.

In the previous release of Entity Framework, there were deal breaker issues in the source control story. In short, it didn't work. I installed Visual Studio 2008 SP1 Beta to check how the new bits behave.

Let us start from the simplest scenario, defining a model with two classes, and commit to source control:


Now, let us say that Jane wants to add a Total property to the Order class:


At the same time, Joe is adding a Name property to the Customer class:


Jane commits first, and then Joe attempts to commit. Here is the result:


This is bad.

In fact, I would say that calling this unacceptable is not going far enough.

I made two unrelated modifications in the model, something that happens... all the time, and it puked on me.

This is not an acceptable Source Control story.

Now, to be fair, I dug a little deeper and tried to find what has cause the conflict. Here is what I find in the Model1.edmx file:


The conflict is in the visualization section of the file. This is a huge improvement over the previous version, but is is still broken. Leaving aside the fact that I have no idea why the visualization information is in the same file as the actual model, I shouldn't get merge conflicts on this trivial a change.

I didn't check the generated code, but there were conflicts there as well, which might cause additional issues. They could be regenerated, I assume.

In the end, I was able to get to the model that I wanted, after manually fixing the merge conflicts:


In summary, this is a huge improvement from the previous version, but it is still fall far from the minimum expected bar.

Please note that I have tested the most trivial scenario that I could, I have no idea what the behavior would be when dealing with more advance scenarios.



Microsoft still believes in exclusive checkout model for source control.


I guess there is no option to have each class in a separate xml file?

Dmitriy Nagirnyak

Oren, I cannot try it.

Could you please tell if it is possible with EF to have many packages of the same model (eg: design Security, Payments, Accounts etc on different surfaces).

If there is no anything like that than EF is just a child-play for demo projects.

Ayende Rahien

Speaking completely off the cuff now, I don't think it is possible with the EF.

I think that the underlying framework supports this, but the UI doesn't.

You are better off asking an EF expert.


At this moment I see these way for solving such problems

1) You are somehow modifiing source control program, i.e. its client part for autoresolving such conflicts

2) You can write some code in your dsl package, which can save/load parts of dsl from multiplefiles. What I know - ActiveWrtier plugin for Castle ActiveRecord generates hbm mappings for each class in different files. So you have to write dsl package, which will save it's information in different files in any source control -friendly format and which will load that information on loading.

Peter Morris

I'm more inclined to agree actually. I prefer a single user changing the "structure" of the model at once, but that many people can edit the individual classes to add method implementation etc.

I see the model as a single conceptual "thing" that should be modified in its entirety.

Ayende Rahien


Consider an application that is in production, but is under continuous development.

If you find a bug in production, you can't apply the changeset to the trunk.

Feature branches are impossible, etc.

This is critical issue

Liviu Uba

I think Microsoft went on a shiny but wrong way with this designers. Even the LINQ designer suffer conceptually the same problem.

What is so hard to have an addin that shows you all the relations visually, but you specify the relations using attributes directly in code?

I wrote myself a tiny orm that is based solely on attributes, and i use an addin to visualize and manage relations. I use a searchable treeview for showing that information, no big graphs that layout silly automatically.

I do not have any problems with Source Control.

Why cannot Microsoft think simple?

Comment preview

Comments have been closed on this topic.


  1. RavenDB Conference 2016–Slides - 13 hours from now
  2. Proposed solution to the low level interview question - about one day from now

There are posts all the way to Jun 02, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series



Main feed Feed Stats
Comments feed   Comments Feed Stats