+972 52-548-6969
Reviewing the Entity Framework Source Control Support
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.
Comments
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?
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.
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.
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.
Peter,
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
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