Readonly Entity Framework Issue

So last couple of posts I have been talking about the new Dynamic Data features in .NET 3.5 SP1. Specifically I am talking about the dynamic scaffolding feature which automatically builds a CRUD operation page directly from the EDMX model. So last week I wrote a post on how to make certain tables readonly.

To reiterate, you would do something like this:

[ReadOnly(true)]
public partial class Course {
}

… and add the rest of the code discussed in my earlier post into your Global.asax. And Course would then become readonly. Unfortunately, if you do this you’ll all parent tables that has a relationship to the readonly table will no longer show a ForeignKey reference dropdown.

What that means is, if you have a table say Enrollment which has a many-to-many relationship to course, the dynamic data relationship manager is not going to give you a dropdown for all the course when you open up an enrollment, like it is supposed to. And the reason for this is that you’ve made the Course table readonly-which prevents FieldTemplate to pull up the ForeignKey_Edit.ascx template, so the ForeignKey.ascx comes up which is just a literal control.

Xbox: Project Natal

Project Natal for Microsoft Xbox will completely change the way we play games. There’s is no controller-you are the controller-and you thought Wii was cool!

Branching and Source Control Management

So we’ve been working really hard on restructuring our code base and our branching pattern. I’ve spent a lot of time reading various books and articles on best practices for branching patterns and source control management. There’s two ideas that I would like to share with you today that I’ve found very useful.

How many branches should you have?
Turns out this is a fairly complex question. The answer in short is: as few branches as you can possibly live with. If your programming practice works with a single branch-great! Don’t change anything – just because people have a production branch, mainline branches, a trunk and all that – you don’t need it. If your projects and project management practices are supported through a single branch continue on. But! If you are having issues and would like to streamline the process then the answer is tricky. So couple of weeks ago this is where we were. Our branching structure was getting out of control and we needed to come up with a way to branch better.

So we started off with a single branch, a mainline branch. The policies for the branch was that: the code builds, there are unit tests at least for all data access functions, and that the code completes a user story.

Since we had already moved to SCRUM, it meant that the mainline branch contain code with completed features only. If you’ve read about SCRUM you know that you cannot start or work on anything else until your user story is completed in full. So that’s what we have on the mainline are bunch of fully completed user stories.

But we have a problem! If we were to only check-in our code when we completed a user-story it could potentially be days without any code checked in. This is a potential problem because the longer you wait to check-in code the worse the merging situation becomes, there’s a greater chance that the integration will fail, and your developers have unchecked in code, which is never a good idea. We wanted to be able to commit as often as possible but the policies on the mainline branch did not allow us to do that. So we created another branch which we called the working branch–and the policy is simple: the code should build. That’s all. It does not even have to be unit tested, the idea is if you are done with a small function, check-it in-so that the continuous integration process builds the project (CruiseControl.NET) can kick in.

It’s important to keep both the mainline and the working line in sync. The working branch should be at most 2-3 days away at most-anything more you are risking merging issues which can become a full-time job.

So finally, we have a production branch which holds the production line. If major issues come up that needs to be fixed in production immediately we create a hotfix branch directly from production, fix the issue, and merge the hotfix with our mainline and working branches.

Which files-types should I check-in?
The last thing I wanted to talk about was on what files should be checked-in to your repository. Fortunately the answer to this is simple: if you can generate the file in some automated fashion then don’t check it in, make it part of your build process. If you cannot, then go ahead check-it in. So for instance, DLLs should be checked-in, if you can build them and create the DLLs. Simple enough!