Check out the announcement for details. Now that everything’s on GitHub, NuGet and TeamCity, this should make newer versions much easier and quicker to release. I hadn’t planned on waiting so long, but upgrading to .NET 4 and adding new … Continue reading →
Cross posted from the AutoMapper blog (which I hope to stop cross-posting, eventually): AutoMapper is now completely moved to GitHub: AutoMapper GitHub I’ve updated the site on CodePlex to reflect this move, and moved all existing content over: All issues … Continue reading →
Simplicity is a good thing. Especially when you want to turn out a site that’s really only a couple of pages, max, you don’t want to spend much time (or any) futzing around with things that you don’t care about. … Continue reading →
I’ve (finally) officially launched the official AutoMapper site at AutoMapper.org. It will be a central location for links to AutoMapper resources (mailing list, source, wiki, blog etc.) as well as a spot for news and announcements. I also have an … Continue reading →
At one point, AutoMapper was not a signed assembly. Until someone asked for it, I went ahead and signed the assembly, and really haven’t had a complaint since. But it seems that signing of OSS projects is a bit of … Continue reading →
Something I’ve been looking at adding to AutoMapper was the idea of doing automatic query projection in the Select query projection in LINQ statements. One downside of AutoMapper is that projection from domain objects still forces the entire do…
In the last post, I posed the question on what to do with .NET framework upgrades and OSS support. I wanted to upgrade AutoMapper to .NET 4, but I didn’t want to leave a lot of folks behind because their project isn’t .NET 4. I had a couple of choices:
Since option #2 didn’t really cause me much extra overhead, I went for that one. To upgrade, I first needed to create a remote branch on github:
Creating a remote branch in git is a little esoteric, as for the most part, git wants to be local. To create this remote branch, I just ran:
More than a little esoteric, but whatever. To then start using this remote branch, I needed to create a remote tracking branch to make it easier to push and pull:
And now my local repository has both remote branches being tracked:
With both branches going, I now set about upgrading the AutoMapper to .NET 4.
Upgrading the AutoMapper code to VS 2010 and .NET 4 was easy enough. I just opened the VS 2008 solution in VS 2010, and the upgrade wizard properly upgraded everything. Upgrading the solution files does not change the target framework, so I still needed to modify all of the project files to target .NET 4:
That was easy enough, and all tests immediately passed. I decided to leave the Silverlight 3.0 projects out of the equation, I still need a better way to support multiple runtimes easily. Some of the app.config files were automatically modified, but there were really no problems upgrading the actual projects to .NET 4.
Upgrading the build, however, was a completely different story.
Most of the build tools I used, including NUnit and psake, were still targeting .NET 3.5. To upgrade these, I first needed to download the latest psake and include the following configuration in my build script:
$framework = ’4.0′
This told psake to use the .NET 4 framework. Next, I needed to tell NUnit to target the .NET 4 framework. I was able to do this by adding the “supportedRuntime” element:
<startup>
<requiredRuntime version="v4.0.20506" />
</startup>
I stuck this in my “nunit-console-x86.exe.config” file, where it already had a commented-out section for me to edit.
The last part I needed to fix was the ILMerge call in my build script. This was much trickier. I needed to modify the call to ILMerge to include the path to the .NET framework. Previously, I only needed to include the version. I created a PS function to get the framework directory:
function Get-FrameworkDirectory()
{
$([System.Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory()
.Replace("v2.0.50727", "v4.0.30319"))
}
Quite lame, as I get the current runtime path and replace the folder name of the .NET 2 version number with .NET 4. I’m sure there are better ways, but hey, it works.
Finally, I just created a property to hold this value:
$framework_dir = Get-FrameworkDirectory
And modified the call to ILMerge to include this value:
ilmerge.exe /targetplatform:"v4,$framework_dir"
Once all that was done, I created a second build on the TeamCity CodeBetter build server:
That’s pretty much it. It was a little hairy upgrading the build, but that’s only because of the tools I use. If I didn’t have Stack Overflow, it would have been much more difficult 
The idea going forward is to apply pull requests and bug fixes to the .NET 3.5 branch, but not any new feature work. I’m not going to delete that branch, so anyone wanting to add new features just needs to fork that branch and send pull requests. Because branches are so easy to manage in github, there’s really no reason for me to just kill the .NET 3.5 version.
Otherwise, I’m getting started on the master branch on version 2.0 work. For those that have forked master and want to now point to the NET35 branch, you can just update your local upstream remote to point to the different branch.
Today I pushed out the 1.1 release of AutoMapper. From the release notes:
Head over to the AutoMapper project site to download the latest version.
The big change for 1.1 is that Silverlight 3.0 is now officially supported. I was able to support all of the features of regular AutoMapper, except for a few pieces that just don’t exist in Silverlight, such as IDataReader etc. Also, I moved the source to GitHub from Google Code, which has made my life much, much easier for dealing with new features, bugs, issues and releases. Enjoy!
Along with the switch of VCS to git came the ability to have much improved workflows that simply weren’t possible in CVCS like TFS or SVN. The nice thing about Git over CVCS is that because of its power, I can choose the workflow I want to use depending on my situation. Most, if not all of this comes from the fact that local branches are cheap, and the commit model of git.
A couple of the things I wanted to shoot for was a clean history and isolating work. With OSS development, I’m juggling a lot of different threads at once. Feature requests come in, bugs come in, new work is going on, pull requests come in, patch files/code detritus comes in, and I don’t want work on any one thing to conflict with the other.
And since work on each thing is very asynchronous in nature, I want to match my git workflow to the actual interaction workflow that I use in the real world. But first, let’s look at how we can visualize our local repository. That’s a huge step in dealing with different kinds of workflows.
I prefer git extensions over gitk and git log –graph. Gitk is a bit of a pain to deal with, and git log attempts to use all the ASCII powers of the interwebs to display a graph of commits. For example, here’s the current AutoMapper commit graph (locally):
Note anything? A clean, linear history. I absolutely detest bizarre, convoluted histories, where I see a tangled web of commits. I have a few different workflows, but all start with a basic rule:
Always branch before doing ANY work.
Because branches are so, so cheap in git, branches become THE way to create parallel workflows.
When I get an issue from CodePlex, twitter, the mailing list or anything, I want to create a workflow that allows me to try and reproduce the issue, but without messing up the mainline master branch. Many times, I’ll have conversations back and forth with other folks over the course of days or weeks, as I try and fix an issue. In those cases, that branch can potentially stick around for a long time and NEVER come back to the master branch.
So first things first: An issue comes in, so I create a branch:
git co –b “SomeIssue”
This builds the following picture in my local repo:
Remember, a branch is really just a lightweight, named pointer to a commit. The “git checkout –b” means to create a branch and checkout that branch immediately. “git checkout” is analogous to the “svn switch” command, except git branches are MUCH simpler than SVN branches.
Next, I make some commit locally to that branch, and usually do something like:
git add .
git commit –m “Some commit message”
This now produces the following picture:
At this point, I usually go two routes. If I can fix the actual issue, then I’ll want to integrate my changes back to the master branch. If I can’t reproduce it, need more information or whatever, I’ll just leave it alone. The really cool thing is that it doesn’t matter. At any time, I can checkout master, start a new branch and continue on. Let’s see what it looks like if there are additional changes that happen on the master branch:
We now see that master is basically ahead of SomeIssue. I might have other branches hanging around as well.
So let’s suppose I want to integrate the SomeIssue branch back to master. Now, if there have been upstream changes and changes locally to master, I’ll want to do a “git pull –rebase”. This is similar to an “svn update”, and “get latest” in TFS. However, there aren’t any changes, so what I really want to do is a rebase, from the SomeIssue branch to the master branch:
git rebase master
This results in the following history now:
Rebase is different than merge in that it re-applies commits from one branch to another. What I’ve done here is basically re-play the commits from the SomeIssue branch onto the master branch, so that there is a clean, linear history.
With that done, I’ll do the normal local build. Finally, I’ll checkout master and rebase or merge, the result is the same (a fast-forward merge):
git checkout master
git rebase SomeIssue
And now my history looks like this:
Now that my branch is “done”, I’ll delete that branch:
git branch –d SomeIssue
And my history now shows SomeIssue is gone:
Because a branch is merely a lightweight pointer to a commit, it’s really no big deal to delete a branch, as the creation and deletion of branches does NOT affect the commits in any way.
Now that my branch is integrated into a clean timeline (without any merge commits), I can push master back to origin.
So that’s it, my basic bug workflow is:
This workflow gives me a couple big advantages. First, I can work on bugs/issues that may never have a resolution, and that’s just fine. In fact, in the original history shown at the top, you can see a couple of branches that went off and never came back. They may never in the future either, and that’s okay.
Several times, I’ll be working on one bug, stop, and work on another. The first bug might have failing tests/compilation, but all that work is on a branch so it doesn’t conflict with other parallel work.
And now that I have two bogus commits in my timeline, I’ll just do a “git reset –hard HEAD~2” and rewind time like nothing happened
For more information about how branches and rebase works, check out the free online Pro Git book:
After putting it through the paces, I’m ready to (finally) announce that the AutoMapper source code has moved to GitHub:
http://github.com/jbogard/AutoMapper
I wanted to wait to “officially” move until I had moved the build over, added new features and processed a few pull requests. For dealing with OSS projects, I really can’t imagine using SVN again, as pull requests and git merges are so much easier than dealing with patch files. Additionally, the branching model of git made my life much, much easier to deal with support requests and bug reports. Git simply and easily supports all the workflows I need to provide a good experience to those using my project, from me adding new features to getting support questions answered quickly and easily.
So can do you contribute? First, check out Jason’s git for Windows developers post:
Next, get over to github and create an account:
Finally, you can check out a few great resources on how to use git and contribute on github:
I really wanted to make sure that the move wasn’t just done to satisfy some personal interest in learning git. But after spending the past few months with AutoMapper on github, it’s just been a much better OSS experience than I had with SVN, and the move can only benefit the project.
Remember, with git, branching is easy and in fact, encouraged!
Actually moving the codebase on GitHub was very easy. GitHub supports migration from SVN, including commit history. GitHub walked me through the process, and all I really needed to do was paste in the SVN url. GitHub did the rest.
The only other semi-difficult piece was to change the CI build on teamcity.codebetter.com. Originally, the version number was populated from the SVN revision number. Since git uses hashes for commits, I had to pick a different method. Instead, I now use the build number in the version number from the TeamCity build. All in all, it took all of about 5 minutes to move the source, and around an hour to rework the build script and get a new build going on TeamCity to point to GitHub instead of SVN.
I was quite apprehensive at first about moving, but it was so ridiculously easy, I couldn’t imagine keeping an OSS project on SVN.
As a side note to other OSS project owners, please please PLEASE get off SVN or any other centralized VCS. It’s not a good model for OSS development. Distributed VCS is the platform to host on going forward.
