In Part One I outlined the goals of this series. This article will go over what eventually happened when I decided to rework my source control system. As of the beginning of this process, I have a bit of a mixed architecture in regard to source control. For my open source project (which I’ll reveal in a later blog post once I’ve cleaned up the code enough for it to not be embarrassing), I use github, as I find it to be the best place to host that sort of thing. For my internal projects (hacky scripts for various things, websites for other people, utility code, etc.), I tend to use VisualSVN, which is currently running on my “server”. Finally, for an upcoming partner project, I’m using Bitbucket. All three approaches work rather well, but I’m mostly irritated with Subversion. I had initially intended to keep source control on my internal server, but after some thought, I realized that really adds a lot of work I’m not interested in doing. Specifically, the following are the issues I have with it.

1. It’s subversion. It’s a nice source control system, but newer ones, such as git, seem to offer a broader array of features. It’s sufficient for me, but if I ever outsource any of the work (which I hope to do someday), it’s going to be a pain.
2. It’s running internally. Initially I considered this a feature, but after traveling a few weeks ago, I realized that being able to access the server would mean using my home VPN to connect. This is an additional point of failure that I’m not prepared to accept (as being unable to reach source control could basically mean that I can’t work remotely). Further, if I wish to allow outsourced labor to connect, I would also have to allow them into my home VPN, a state of affairs that, frankly, is not happening.
3. I think branch per feature will be important once I have a product or two in the wild. This can be done on subversion, but git is much cleaner in my opinion and is better understood by a larger audience.
   After consulting with a number of friends and comparing features, I decided to go with (VisualStudio.com)[http://www.VisualStudio.com]. Besides offering both git and TFS hosting, it also lets me choose from a number of templates for scrum, track issues, run automated builds and it integrates with Visual Studio 2013, meaning no more slugging it out with git on the command line, except for a few edge cases. Plus, it ties into my Visual Studio login, which means that I can access my repositories without keeping track of yet another login.

Signing up was very quick and easy, as I already had a Microsoft account for Bizspark.

Once you start setting up the account, you are able to pick a friendly URL for accessing your stuff. You’ll also notice a number of features on the right, including load testing and build that come free with the account.

Once in, you are prompted to create your first project, which will then be added to source control and made available to your visual studio installation. That’s pretty much all that’s required. After that, integration with Visual Studio is smooth.

I really want to apologize to the readers. I expected this to be a long, detailed discussion of how I set up git on my home server and configured all the fun with SSH keys and the like. I never expected a Microsoft site to actually give me exactly what I want, especially at a price and difficulty level so low that it beat all other options I dreamed up. Heck, I even have a ticketing system for bugs and features, which replaces the old scratch pad I have. Not to worry though, future blog posts will be much more difficult and lengthy. And it’s extra nice that it solves a lot of my issues with git in a mostly acceptable manner, as that was the primary reason I was avoiding git for the early stages.