TicketDesk 3 Dev Diary – Source Control and Source Hosting

source code hostingBefore any good project gets further than a mission statement, it needs source control. Typically, I don’t even create a project file without first creating a source repository in which to put it. But I’ve not been that happy with CodePlex, so I’ve decided to move the project to GitHub and switch to the Git source control system.

Source Control Systems

TicketDesk 1 and 2 were hosted at CodePlex using Microsoft’s Team Foundation source control system. After 5 years of trying, I eventually developed a deep and lasting hatred for all things TFS. When CodePlex added support for Mercurial, I had TicketDesk migrated as soon as I could.

I use both Mercurial and Git, but I tend to prefer Mercurial. Both are highly capable systems, but for windows development, the experience around Mercurial is much better. Mercurial installs easily, runs smoothly, is easy to learn, easy to use, and comes with a great GUI out of the box.

In contrast, running Git on windows requires installing a whole mess of junk to bridge the gap between Linux and Windows… and that just gets you to the command-line tools. There are several third party Git GUIs, but most of them are terrible. GitExtensions is the best, though still ugly and counter-intuitive compared to TortoiseHG.

Fortunately, there are great extensions available for Visual Studio no matter which system you go with.

About command lines… I love having the option of a command line, but I hate using a command line as my primary user interface. Command lines are fine for advanced scenarios, automation, or propping up a nice GUI… but for something I interact with as often as my source control system, I want a good GUI!

Repository Hosting

I like CodePlex, but it lags behind BitBucket and GitHub in both features and popularity. CodePlex’s release management features are way ahead of the competition, and the site makes a better end-to-end product hosting service than most of its competitors.

CodePlex elegantly handles product information, downloadable releases, source code, support forums, bug tracking, and documentation. I am completely comfortable sending an end-user to TicketDesk’s CodePlex site to submit bugs or ask questions. In contrast, I would never send an end-user to GitHub or BitBucket to get support for one of my products.

As much as I like CodePlex though, I’ve also had many bad experiences with them, particularly around support and reliability. As an example, my routine request to have TicketDesk converted to mercurial went unanswered for more than 3 months, and it wasn’t handled very well when they did get to it. CodePlex often doesn’t perform very well, though this seems to have improved some recently. CodePlex also isn’t very popular, which makes projects there less discoverable, and people less likely to fork or contribute.

I use Bitbucket extensively for my professional code. Bitbucket lagged behind GitHub for a long time, but in the last year it has improved rapidly. Now, it rivals or exceeds GitHub in most of the areas I care about most. They’ve added support for Git repositories too, though I’ve only used it with Mercurial. I like BitBucket’s pricing model, and it supports organizational team accounts, as well as individual users  –perfect for corporate projects where an individual doesn’t directly own the repositories.

GitHub is crazy popular, and for “social coding” popularity is everything. If you are using Git, and your project is public, then GitHub is the obvious choice. It has amazing features, and sets the bar by which everyone else is measured. The only major complaint I have is the lack of a release management system. GitHub doesn’t make the best full-service project hosting site, but it does a bang-up job with the core mission of source code collaboration. GitHub’s pricing is perfect for open source projects and private repositories, but awkward for some corporate scenarios.

Why Git and GitHub for TicketDesk 3?

    • Git
      • I use Git a lot when working with other peoples’ projects, but I have not used it extensively for my own. I could use more end-to-end experience with it.
      • The typical workflow with Git is perfect for public projects like TicketDesk. Private branches, history culling, and similar features all help keep the public repository clean, and focused only on commits that moved the project forward.
      • Even among the .Net developer community, Git is the more popular option. Using Git will hopefully encourage more people to contribute.
      • Git has better integration with Windows Azure, and I do hope to make TicketDesk 3 an Azure deployable application. This is a minor plus, but worth a mention.
    • GitHub
      • Since I’ve chosen Git, GitHub is the inevitable choice for hosting.
      • Hosting at GitHub should result in higher visibility for the project, which I hope translates into more people discovering TicketDesk.
      • GitHub’s best features are those designed to enable independent programmers to contribute and collaborate on public projects; something I’d like to see happen more frequently with TicketDesk.

What about the CodePlex project?

I do plan to keep the CodePlex project around. I will likely continue to push packaged releases there, especially since GitHub doesn’t do much for release management. I may push occasional source updates to CodePlex when the code reaches major milestones.

The TicketDesk 3 repository is already on GitHub, but is private for now. Once I have a good start, I’ll open it up to the public.

Leave a Reply

Your email address will not be published. Required fields are marked *