Offline version control is nice. Reviewing logs, viewing diffs, and applying merges is dramatically faster when everything is local.

It would be nice to be able to use my ticketing system offline also. I don’t like the context switch of leaving my editor to go over to my web-based ticket system when I want to make a note of something to do later.

Completely unrelated to offline access is the idea that most of the time, my ticketing system and my source control systems are barely aware of eachother.

For example, when I write a “fix this low-priority bug” ticket, it isn’t obvious what revision and branch of my code I’m talking about. Sure, I can add that information manually, and maybe my ticket system will even require me to do that, but I can very easily put incorrect information in there.

I’m thinking about starting an open-source project to make this happen. Please leave a comment with your thoughts (if you have any).

Goals

• Allow offline access to reading and writing tickets.
• Unify source control with ticketing so that tasks, requested features, and bug reports are linked with the relevant code.

What fields are in a ticket?

I’ve used bugzilla, various homemade ticketing systems, trac, and redmine. They all have at least these fields in every ticket:

• Globally unique ID
• Title
• Description
• Comments
• Deadline
• Status
• Priority
• Assigned To

A decent ticketing system usually also supports category keywords, lists of interested people that want to be included in discussions, links to external files, estimated time cost, etc.

Also, a decent ticketing system has lots of nice aggregate views of tickets.

I don’t want to talk about building a *decent* distributed system. I’ll settle for a toy one that just barely works.

Text file approach

Put each ticket in a separate file. Name the files like “make-login-box-green.txt”. Use some markup to divide the file into fields.

Append comments and follow-up notes to the end of the ticket.

This is easy and intuitive. I can use vim to write the tickets. The source control system can track changes in the text file itself to notice changes. So, the source control system reveals if I renamed the title.

The disadvantage is that doing diffs on different versions of a text file just notices text differences.

For example, if I rename a ticket’s title from one line to two lines, and then also change the deadline, all I can see in my report of what changes is the information about what characters on what lines are different.

Local client approach

Use something like the text file approach, with a few bells and whistles.

Instead of just firing up vim/emacs/notepad/textmate and starting typing, I want to use a simple local app like this:

$ cd ~/projects/myproj1/trunk/tickets
$ dist-ticket new --title "Change color of login buttons from green to pink"

Then the app would open $EDITOR with a new file that includes the template of a new ticket, populated with the command-line options passed in.

This local client could create the new file with a file name that includes a UUID function to generate globally unique file names.

The app would also be able to compare diffs between revisions of tickets, like this:

$ dist-ticket diff -r 1:2 ticket-123.txt
Title renamed from "Change color of login buttons from green to pink"
to "Change login buttons style"
Deadline extended by six months.
Changed priority from High to Low.

Of course, the underlying source control system would still be able to show the text differences between the two files. But the dist-ticket script would apply a little bit more intelligence.

Stuff I’m pretty sure about

I want this thing to be agnostic to the underlying source control system. People using centralized source control should still be able to use it and people using some homemade crap should all be able to use it.

Initially it might not be possible to have dist-ticket go and talk to the VCS and get revisions. Instead of the dist-ticket diff thing above, we might need to do this at first:

$ bzr cat -r 1 ticket-123.txt > /tmp/rev1.txt
$ bzr cat -r 2 ticket-123.txt > /tmp/rev2.txt
$ dist-ticket diff /tmp/rev1.txt /tmp/rev2.txt

So after the interface is defined, I can build the implementations for the VCS that I care about. The first two lines could be built into dist-ticket.

Associating tickets, branches, and revisions

I know I want to link my source control system somehow to my ticketing system. I see a couple of ways to do it:

• Underneath each branch, make a top-level directory called tickets. Then tickets would be seen as related to that branch. One ticket would be linked to exactly one branch.

  OR

• Keep tickets in some place completely outside the branches directory.

  Make some other intermediate data structure that holds a many-to-many relationsip between tickets and branches.

I like the second approach a lot more than the first approach. I would love to be able to look backward and see how I started working on feature X95321 as of revision 123, and then marked it complete as of revision 148. It would be nice to easily see which files are relevant and which ones are not relevant.

Maybe I would need to hack the VCS commit process somehow track relevant tickets per each commit. Maybe I could just store extra text in the comment part of the commit.