With SharePoint 2010 and Visual Studio 2010 the ability to be a productive developer was key and there is tight out-of-the-box integration and this means that it is easy for SharePoint developers to put code into source control easily. Hilton Giesnow covers this brilliantly in a video he has: http://bit.ly/g71Gnb
Imagine a number of dedicated SharePoint developers, they may have an enterprise ALM solution like TFS and on their own machines have SharePoint 2010 Developer and VS2010 installed and life is good – but what about the individual, or ad-hoc, developer?
The problem for him is that installing SharePoint 2010 is a resource hog and you may not want it running all the time (what Hilton nicely calls the 9 to 12 development) and what about if you switching between projects, how do you switch SharePoint? The solution I found, is to have a virtual machine (VM) for SharePoint with the dev tools installed and do all work on the VM. This is great because the overhead is only there when you need it and you can easily switch between different virtual environments. The downside: source code management.
Sure you can hook up the VM to the network and manage code using the source control as you are used too, but this isn’t always easy or possible, so what else you can do? I had this problem recently where the source control is on one domain and my development was another domain. I choose to use the Mercurial Distributed Version Control System (DVCS) and I thought I would share this experience with you.
DVCS differs from “traditional” source control like TFS or SubVersion which has a client/server model where each developer is a client talking to a central server, however in DVCS every developer is their own server and does pushes/pulls (think like a sync) between other developers.
What this enables is a very lightweight set of tools installed along side SharePoint and the developer tools on the VM. At the end of each day I could run Mercurial on my machine and pull the source control down to my own machine. This meant the VM had the code and my “real” machine had the code. Then this code could easily be checked into the corporate source control system creating another backup and ensuring compliance with source management policies!
This has been a very exciting project and this configuration really made the management of the source code very smooth.