I remember the first time I was introduced to source code version control systems. Back then our team was using Visual Basic 5 and I was just a rookie developer probably the most junior one. Everyone was against it so I was given the task of selecting a tool and introduce it to the team. At the time our team only heard of Visual SourceSafe 5 which came with Visual Studio 97 (VB 5). At first nobody in our team liked the idea since it was horrible to migrate from no source control to the worst source control system but as we go along we developed a way to work around the limitations of SourceSafe. All of our development team were located at the same office and we only work during work hours and we all used our workstations to do all development work. We were happy for the time being.
Part-timers/contractors
Moving forward five years and it was the time that TFS 2005 together with VS 2005 was released. I was excited to try out the product which was replacing SourceSafe and how it would change our way of work. Honestly it was a huge leap forward compared to SourceSafe but it couldn’t handle the new challenges related to distributed application developments. This time we had a couple of team members who are not always connected to our intranet and will be working while disconnected. Suddenly we started facing new challenges related to merging and shelved changesets. In order to work disconnected I had to detach the solution from source control binding and rebind it when I have a connection our network and it quickly become apparent to most of us that this has a huge productivity impact on the whole team. Some team members even suggested that we dump source control all together and go with the ‘stone age’ technique of communicating changes through shared folders on a server. To be honest this came from a guy who never checks in/commit his code even for a week saying that he is still working on his tasks and he is not done yet. In fact he didn’t stay on the project very long since this it was not an issue of source control rather personality.
When VS 2008 was released I was hoping that TFS would add this capabilities but it again failed short of addressing distributed source control management issues. It was at the peak of my frustration that I heard about DVCS (distributed version control systems) like Git and Mercurial. The principle behind DVCS differs a great deal from that of a centralized and connected systems, I found if very difficult to understand the concept at first but as time passes by I immediately fall in love with them.
Mindset change
Understanding DVCS was only the tip of the iceberg of challenges I was about to face the prominent one being trying to advocate them in a team where no one had heard of them. I have always been responsible for administering and managing source control systems in almost every team I participated but this time it was a little more challenging. The first thing I did was trying to migrate our team from TFS to Subversion since it is still a centralized system and allows to make changes while disconnected from the network. Then again another set of problems surfaced namely ‘Merge Hell’. Everyone in the team never had a problem of merging since I deliberately locked sensitive files like .sln, and .dbml files so that they can only be edited by one user at a time to avoid conflicts. But this time it became an everyday event to resolve conflicts. I still like how svn handles merges for the most part but the team’s main complaint was that they keep on loosing their changes trying to resolve conflicts but this somehow becomes less and less of a problem as the team learns and starts to understand how the whole scenario of conflict resolution works.
EDMX – Source Control Kryptonite
I have to pick one of the most notorious files to merge entity framework’s desinger (.edmx) file has to be it. Because of the fact that .edmx are xml files you would think there is no reason source control systems are unable to handle merging these files well you would be wrong. EDMX files have a very strict structure to handle the conceptual, logical and mapping of entity objects with database objects and you can’t just treat them as simple text files like you would with a C# or VB code and depending on the number of database objects you placed on your diagram you might be forced to skim through thousand lines of xml markup - yea it is horrible. And God forbid if you messed up one element or attribute then everything that depends on the diagram will blowup right in your face.
EDMX Hate!
Now that I have successfully scared the hell out of you regarding the use of .edmx files you might be saying ‘is there a solution to it?”. Well there is but it might or might not be applicable to your situation. In fact it is not only EF designer files that pose this kind of problem to source control systems, there are a number of files within visual studio that are composed by xml markup (I mainly work in Visual Studio but this issue will be applicable to other IDEs and platforms too) and you will be facing this problem quite often. The solution I have followed to come across this issue are the following:
- Adopt DVCS
- Restructure the solution.
The biggest advantage of DVCS is the fact that everyone will have a copy of the source code repository on their machine allowing them to make changes as they wish plus commit their changes to their own local repository. This solved the problem we were facing during resolving conflicts in svn where by developers were loosing their changes when merging. In addition to the easy merge process all commits are treated as a single changeset making the changes you made in different files a single unit. I have to admit that DVCS has their own learning curve but it is definitely worth it.
The other approach is only applicable if you are working with EF and using the supplied designer to define your model and mapping. As I said earlier our team heavily utilizes EF as our choice of data access method but it’s file structure (.edmx) proves to be a huge pain when it is modified at different developer workstations at the same time. The solutions we found to this problem is to migrate to the more recent version of EF (4.1 and above) and embrace the Code First approach. This way we were able to define our models and the mapping with the corresponding tables/views using simple C# classes and no more xml based .edmx files. Well there you have to analyze your solution carefully before you make the switch; namely from EF 4 and earlier based ObjectContext to the newer one based on DbContext. Nonetheless we were able to solve this problem by introducing DVCS and a little bit of EF Code First magic into our practices.
Well one might argue that there is still value in centralized source control systems and I completely agree. If you are practicing CI (continuous integration) to automate your build process, you will face a challenge since your code is dispersed all over your team and there is no concept of centralized repo in Mercurial/Git for instance. To come across this problem you might use one of the many code hosting sites which support these systems like github.com, bitbucket.org to mention some. In a follow-up post I’ll try to talk about some of the lessons and best practices that made the transition easier meanwhile if you are interested in learning about DVCS you can start with hg init by introducing yourself to Mercurial (my choice of DVCS).
Cheers!
Yared Ayalew 