Nick Heppleston, a fellow BizTalk blogger and
user of my PipelineTesting library, left
a comment
on a recent post asking why I chose to put the library code on GitHub instead
of CodePlex. I think it’s a fair question,
so let me provide some context.

As many of you are probably aware of it by now, there has been much talk lately about
Distributed Version Control Systems (DVCS), as an alternative to the more traditional,
centralized control systems that have been common in the past (and still are). DVCS
has gained a lot of traction lately, particularly with Open Source projects because
it really suits the already distributed nature of Open Source development.

For a long time I remained fairly skeptical of DVCS tools. To be honest, I just didn’t
get what the fuzz was about and centralized systems had worked just fine for me. I
use CVS, Subversion and Team Foundation Server on a regular basis, and you can use
all of them successfully with your projects. Obviously, each one has its strengths
and issues, but they are all very usable tools.

However, during last year I’ve been working on a bunch of different projects where
the workflow that suited my work style and my requirements best started to make using
a centralized source control system a bit harder than it used to be before.

This made me realize that for some of the things I do, a centralized control system
just doesn’t cut it anymore. In other words, I crossed some invisible threshold where
the SCCS stopped being an asset and started becoming a liability. Instead of having
source control be a painless, frictionless process, it was becoming something I dread
to deal with. And that’s when I finally understood what DVCS was all about.

Why GIT?

git-logo So
at that point I started to look into DVCS tools and playing a bit with them. There’s
a good discussion of some of
the most important DVCS tools around, but in the end I finally settled for GIT,
using the msysgit installation on
my windows machines.

So far, I haven’t really run into any really significant issues when running msysgit;
the core stuff seems pretty solid, at least in my experience. I know there are some
issues with git-svn in current builds, but I haven’t used it yet so I can’t comment
on that.

I’m still very much a newbie at this, but I’m slowly getting the hang of it, and so
far, I’m really liking it. Some aspects of git I really like are:

  • Speed: It’s pretty fast in most operations, even with large source code files (like
    tool-generated ones).
  • Local branches: I love being able to create and switch between branches very easily
    and fast. Once you realize how easy it is to use them, you start taking advantage
    of branching a lot more than on regular, centralized version control systems.
  • Single work-tree: Not having to maintain N-copies at the same time of your work directory
    when you’re dealing with N-branches is a real plus in many cases. Of course, you can
    choose to do so if you like, but it’s no necessary, like with other tools.

Why PipelineTesting?

I’ve always shared the code of my PipelineTesting library through this website. However,
I was only publishing snapshots of the code, and while that was fine given how few
people use it, it was sometimes a drag. I really did want to share the code more broadly
and make it easier to get to some of the changes I was working on even when I had
not explicitly released a new official version of the library.

Last year I even commented a bit on this topic and asked
for feedback
about what the best place to host the code for some of my projects
might be, but in the end I didn’t make any decision about it.

Why not CodePlex?

codeplex CodePlex
is a fine site for publishing and hosting your open source projects. I was skeptical
about it at first, but it really took off and has a number of things going for it.

The greatest strength that CodePlex has is precisely that it’s a Microsoft-technology
oriented site. This means that it is a natural choice both when publishing projects
that explicitly target the MS stack, and when you’re looking for open source projects
based on said technology.

I think that, overall, the CodePlex team has done a great job of keeping the site
running and making sure it became a viable and valuable service to the community (and
Microsoft itself).

The downside of CodePlex is, unfortunately, the technology it is based on: Team Foundation
System. TFS is a fine, robust, centralized source control tool. But it also has a
few things that manage to take the fun out of using it:

  • The support for working disconnected from the centralized server is just not good
    enough. Sure, it has improved a bit since the initial release, but it is far from
    a friction-less experience.
  • The TFS Client, integrated into Visual Studio. This is supposed to be an asset, but,
    honestly, I don’t always want my source control integrated into my IDE. It can be
    good sometimes, but it can also be very painful.

Just to set the record straight: Yes, I am aware of the command line tools for driving
TFS, and that’s certainly an option. Yes, I’m also aware of SvnBridge,
which I haven’t used myself yet, and it is a really good option and addition to CodePlex,
but means running yet another tool.

Why GitHub?

github The
surest way to get proficient at something is to do it. I want to learn more about
DVCS so that I can improve my workflow, and that means using my tool of choice.

For the time being, I’m choosing to stick with git for my personal projects (and some
of my work). Given this choice, GitHub was a natural choice as to host my public stuff.

There are several aspects about GitHub that I like, but most of all, its that it is
very simple overall, easy to get started with, and mostly stays out of my way. I also
find the social aspects of it very intriguing, though naturally I’m not using those

Of course, not everything is perfect in GitHub-land. Some will argue that it doesn’t
offer as many features as CodePlex in some aspects (like no forums) but that doesn’t
bother me at this point, as I don’t really need that for now.

A bigger issue, however, could be that GitHub is not yet a very visible site among
the .NET/BizTalk communities. Heck, I’m pretty sure PipelineTesting is the only BizTalk-related
project on it :-).
I think that anyone looking for my library is probably going to find it through this
weblog first, so I’m not that worried about it, and the BizTalk community itself isn’t
all that large (it has grown enormously, but it’s still small by comparison).

What’s next?

I plan to continue working on PipelineTesting and I have a few features in mind for
the next release. If anyone wants to contribute or has suggestions/bugs, please let
me know about it!

I will continue to offer a copy of the
library for download
that includes a snapshot of the source code and a pre-compiled
copy of the library, like I’ve been doing so far. People shouldn’t have to install
git just to get a copy of the library and use it, unless they need something in the
code that’s not yet in an "official" build. Of course, I’m a nice guy, so
if you really really need it, just ask :-).

I also plan to start taking advantage of some GitHub features. In particular, I want
to migrate some of the "documentation" that I’ve written over time as blog
posts to a more appropriate format that’s easier to maintain and to use. For this,
I want to put the GitHub Wiki to use and also add a proper readme file to make it
easier to get started with the library.