I posted quite a while ago about using the Bazaar distributed version control system to provide offline capabilities for TFS. I've still been using it that way, but I've found that Bazaar is working quite well for me as a personal, low overhead source control system.

One of the nicer things about Bazaar is the easy hosting and sharing of repositories. All you need for a read-only repository is to put it up on web server. No special configuration required. And yet, every time I tried putting a branch up on this server, it failed.

Turned out that the problem comes down to the bazaar repository format. More specifically, there are filenames in there without file extensions, and IIS just doesn't like that (unless you put in a wildcard mapping which has tons of other issues). I was at a loss, when I remembered that I can just fake it with ASP.NET.

The trick was to give the request an extension. And there's an extension already configured that's perfect here - .ashx, or the ASP.NET HTTP Handler. So what I did was build a hander that takes an url like this:

http://www.tavaresstudios.com/branches.ashx/[Repository Name]/... bzr paths here ...

and feed the resulting files back to the bazaar client. The actual path gets munged a little. I don't need to worry about encoding or anything else, just stream the bytes straight back out to the client.

Here's the code:

using System;
using System.Web;
using System.IO;
using System.Configuration;

/// <summary>
/// A small <see cref="IHttpHandler"/> that returns the contents of the file
/// under given pathdata. Used to serve up files that don't have an extension.
/// </summary>
public class BranchesHandler : IHttpHandler
{
    public void ProcessRequest(HttpContext context)
    {
        string requestedPath = context.Request.PathInfo;
        string root = GetBranchRoot();

        string resultPath = context.Request.MapPath(root + requestedPath, root, false);
        string rootPath = context.Request.MapPath(".", root, false);

        if (!resultPath.StartsWith(rootPath))
        {
            throw new HttpException(404, "File not found");
        }


        context.Response.ContentType = "application/octet-stream";
        CopyFileToResponse(resultPath, context.Response);
    }

    public bool IsReusable
    {
        get
        {
            return false;
        }
    }

    private string GetBranchRoot()
    {
        return ConfigurationManager.AppSettings["BranchRoot"];
    }

    private void CopyFileToResponse(string filePath, HttpResponse response)
    {
        if (!File.Exists(filePath))
        {
            throw new HttpException(404, "File not found");
        }

        response.TransmitFile(filePath);
    }
}

As I build future samples, I'll still make them available as .zip files, but I'm also planning to put the bazaar repository up as well for folks who want to track them.

At p&p, we use Microsoft Team Foundation Server for work item tracking and source code control. This comes as a surprise to exactly zero people I'm sure.

TFS did take some getting used to, but after working with it for a while it's gotten pretty comfortable. At least while I'm in the office. There's one nagging problem with it; when I go home, or out of the office, I've got to have corpnet access to work on the project. TFS tracks on the server which files you're editing, which means that even working on a local copy without doing a checkin requires access to the TFS server.

While I do have remote access, it's a pain, it's slow (I live about three miles beyond the borders of civilization, apparently, and my home can't get real broadband service), and at times unreliable. I've resorted to turning all the read-only bits off locally, editing away, then using the Team Foundation Power Tools uu and online commands to get synced back up.

This worked, but I hate working without a net. I still want source control, even just for local projects. And the tfpt commands get really confused if you delete files, so I needed a way to track that somehow, other than a pad of paper.

I just came up with an idea that I'm trying out, and thought I'd share.

I've been playing for a few months with a new open source source control system called Bazaar. It's intended as a distributed version control system where people ship patches to each other and it help manage the merges and whatnot (kind of like GIT). It's highly portable and plays nicely on Windows (unlike GIT). You do need to be comfortable at the command line, but that's not a problem for me. One of the nicest things for my purposes is that there's no server to set up. Each working tree is it's own working repository. You just type "bzr init ." and you've got source control on that directory. No need to set up a Subversion server, for example. And sharing my branches are as easy as emailing a file. Not that I've done that yet; this was just for me.

Anyway, back to the point. Here's what I'm doing. First, I made my TFS workspace into a bazaar repository as well. This means that as I make changes in TFS, bazaar will treat them as changes to the working copy, and I can check them into bazaar too. Second, I created a separate bazaar branch for my offline work. This gives me local source control; as long as I'm working in my local branch, I don't need to be connected to TFS at all.

Here's the money shot. Bazaar supports easy merging between branches. When I'm ready to commit to TFS, I push my changes from my local branch back to the TFS bazaar branch. Then I check that into TFS. Similarly, I can do a "get latest" in TFS, check into the master bazaar branch, then merge those changes into my local copy.

It's not quite seamless (I still need to play with tfpt to get the checkouts set up right) but so far it's working out a LOT better than working completely disconnected from source code control. Having local source code control makes this work a lot more agile; I can freely delete and modify stuff locally, check in or even branch some more, and I don't have to push back up to the server until I'm ready.

So far this system has been in use for about four hours, but so far so good. I'll update later once I've got more experience with it.