Ian Bicking: the old part of his blog

Towards a More Perfect Version Control

Havoc Pennington refers to some of his thoughts on version control in reaction to my last two posts on version control.

What he describes is very user-interface-oriented, from the perspective of bug and patch tracking as much as version control. It makes for an interesting overlap. Here's a kind of use case he gives:

  1. The version control system keeps track of how to submit patches (mailing list, bugzilla, etc.) and has a "submit patch" command. (Prereq: the system has a concept of a patch you're working on for submission)
  2. The version control system tracks submitted patches for the maintainer and supports easy review and acceptance/rejection of them.
  3. Easy way to have a conversation about any patch (as we do now in bugzilla typically)
  4. Allow the maintainer to easily hack on the patch, merge their changes with it, and then bounce the patch back to the submitter for more work - I often want to just fix the nitpicks instead of writing them down, then give someone the patch back to fix the big stuff.
  5. Often you want to commit a number of times before you submit a patch officially (sometimes people will make a CVS branch for this). A nice feature would be to avoid the need to do this manually; just have the developer tools automatically "commit" every time you save from the editor, or even make the whole undo buffer persistent. Much more plausible with monotone than with CVS.

I can imagine doing this entirely within version control:

  1. The version control system makes branching really easy. You start editing your checkout, and then there's a kind of "commit as branch" command. If it's a distributed system then there isn't really anything like a "checkout" (which is fine), but something more like "upload as branch".

  2. Perhaps simply by filename convention, tracking is part of the version control system. So if you wanted to submit the patch for review, maybe you'd put request-review.txt in the system, with a note of explanation (what the branch accomplishes or fixes).

    The entire repository, with all branches, should be well indexed. It should include workflow-related concepts. This could be as simple as text tags indicating status that are manually edited.

    Thinking a little more -- tag the branch "for-review" (this is not like Subversion "tags"; more like setting a Subversion property). Add a property "author" that has your information. Another property lists people who are interested in being notified about changes to the branch. Another rule notifies maintainer(s) that something has been submitted. And an indexer displays what branches are in what states (for-review, in-review, rejected, accepted, etc).

  3. The conversation takes place in more text files. Maybe the VC frontend handles the formatting. Or not, whatever.

    In addition to indexing there's notification. You can register your interest in a branch. Maybe an email gateway for these conversations, where the conversation is appended to that discussion file. It's like the Talk: pages in Wikipedia.

  4. Good merging tools make it easy to bring together branches.

    When you want to change a patch but submit back to the author for further changes, you just edit their branch. Non-authoritative branches (like those that are submitted by non-maintainers) are editable by everyone. You could even simply add comments inline to the code about issues you see with the changes.

    I think the ability for maintainers to edit non-trunk (and non-official-branch) code is a really important way to communicate with contributors. And for contributors to communicate with each other; this shouldn't be a wheel-and-spoke system centered around one integrator.

  5. Autocommit is a separate issue, I think. It would be fine if an editor did this, but it's not something that screams out to me.

    History is more easily available if everything is a branch, not a patch, and branches have history and you can continue development on them without being merged into the trunk.

This doesn't really address issue trackers. Issue trackers are lists of problems without solutions, and source control typically holds solutions. If the version control (or maybe just the tools built around it) was really powerful, then potentially it could be a backend for issue tracking, where "issues" are special files or directories. But the workflow for issues is typically much more automated and structured than for generic "source".

Created 12 Aug '05

Comments:

In our enterprise development one of the things that I have been working on putting together is a way that error reporting, trouble ticketing, version control, unit test coverage, and IDE are tied together.

If an unexplained error happens a support person is automatically assigned a trouble ticket and emailed. Tech does initial research and closes out ticket because he could handle the problem or bucks it up to the developers with what ever information he could glean. Developer researches, resolves the issue if he can, generates additional unit testing. New trouble ticket is generated for each developer to peer review the new unit tests and the patch. Reports at the end of the month about what code was changed and who changed it, did it cause problems, what kind of problems and how was it fixed.

I have been using Roundup as an issue management for a while and I do already create trouble tickets based on events in applications via email. The next step is tying in the versioning system. There has been many developments with Roundup and SVN in the last few months. So I think that this is what I need to set up next. My dream isn't too far away.

# count0

I think we are already most of the way there with Monotone:.

I have only been trying it out for a little while now, but it has a few features that could be glued (with a little bit of Python or something) to Bugzilla or any number of other development tracking tools.

  1. It supports arbitrary metadata attached to submissions and changes. This could be used to track the status of a patch, where the current discussion is taking place, a bug number, etc.
  2. It supports multiple head revisions. So people working on the patch can simply work on a seperate head until the patch is approved, then merge it into the "official" head.
  3. It is very configurable. It uses Lua: as its configuration language, and it has a large number of hooks that can be customized.
  4. It has a "scripting" version for its commands to make it easy to automate most tasks.

I guess all that is needed is a bit of work to tie it all together. There are already a few projects that integrate with it, but I couldn't find any that integrate with bug tracking or email patch submission systems.

# Alan Falloon

"If the version control (or maybe just the tools built around it) was really powerful, then potentially it could be a backend for issue tracking, where "issues" are special files or directories."

There seems to be a bit of convergence on this idea; I know we've tossed around such stuff some in monotone, especially when we were also experimenting with using our regression test suite as a bug tracking system -- I think that's a very powerful bit of integration for such a system to include, by the way -- and Aaron Bentley's actually put together a system called Bugs Everywhere.

My biggest problem with such a scheme is that part of what issue trackers do is track discussions; and discussions do not follow branch semantics. You generally want your discussions to be global -- gathering together comments from two different branches to figure out what's been done on a bug sounds like a royal pain. OTOH, bug states (open, closed, ...) very much do follow branch semantics -- closing a bug in a branch, then having it closed on mainline when the branch is integrated, is very slick. I'm not sure what the right solution is.

I'm hoping that as these systems get a little more mature we'll see a lot more work on workflow processes and stuff...

# Nathaniel Smith

For coupling issue (and ticket) tracking and source control I've been very impressed by Trac

We're currently using it for ad-hoc documentation, source code viewing, and ticket tracking (we started with issues but now every piece of work has an associated ticket). It's really nice being able to cross reference change sets, wiki pages and tickets in the same environment.

# Andy Todd

I've used Trac as an issue tracker, and I've liked it well enough as that. I somewhat prefer Roundup for more involved issue tracking, but I think Trac has a more accessible UI for public projects. But I haven't felt any real motivation to use any of its other features (or Roundup Subversion integration for that matter). I don't need Yet Another Wiki (and worse Yet Another Wiki Markup). That's not how I want to keep my documentation. The Subversion integration might be good, but I never remember to link them up. They are too far away from each other, IMHO; web and svn client are very different modes for me.

# Ian Bicking