I decided to call it dbugt, and I've been planning out just how it would work a lot lately. I decided that it would be important to describe how the distributed approach would be used in actual bug support workflows and so I've created diagrams of branching, and merging to show some situations where common distributed paradigms would come in handy. I'm of the opinion that backing this with a regular old version control filesystem would not be a suitable approach since merging would be difficult if a bug were stored as a single file and if we end up breaking the bug into a number of atomic files, we've basically implemented a repository format inside another repository, so it seems like a better idea to just pull that repository out into its own.

The Repository Format breaks the repository into three distinct objects, Bug objects which include a collection of change objects, and change objects which are a tree of Atoms which describe specific changes to the Bug metadata. Each Atom is a single unit of change, in this way it's easier to merge and handle these repository changes. All objects in the repository are addressed by crytographic hash and include referential markers in their body so that the Bug graph can be built from the Bug data alone.

The Repository format tree might look something like this.

  Bug_ID
 /
|
|                      timestamp -> time/tz
|                     /
|           change_1-<
|          /          \
 \        /            owner -> alexbl
  Bug_ID-<
 /        \
|          \
|           \
|            \            status -> resolved
|             \          /
|              change_2-<
|                        \
|                         note_add: fixed!
|
 \
  Bug_ID

Branch situation: I had discussed briefly the prospect of resolving conflicts by branching instead of merging and conflict resolution. I've now had some more time to flesh that idea out and I've diagramed and described a situation where that might happen:

Change A: submitted at 12pm (bug initialization)
Change B: submitted at 2pm added at 2pm
Change C: submitted at 3pm added at 1pm

             submitter -> alexbl
            /
         A-<---timestamp -> 1178707906/-0700
        /   \
Bug_ID-<     summary -> ENOTIME
        \
         *
         /\      owner -> alexbl
       *  |     /
      /   *--B-<
      |   |     \
      |   |      status -> analyzed
      |   |
      |   |   owner -> fred
      |   |  /
      |   C-<
      \      \
       *------note_add: I think this is only on Platform X

What we have here is a new bug which has branched in two directions. A bug was submitted which two actors opted to work on, so the bug was branched into two seperate trees. When Change C is submitted the repository would detect a conflict and either automatically resolve it by a forced branch, or in this case the bug could be resolved with an interactive branch. The user was asked if a branch was an appropriate action, and after the user decided that it was they were asked if the non-conflicting change operations were appropriate to be rebased on to the first branch. Since the user felt the note might be useful to the person that submitted change B he opted to rebase the note onto the other branch. Note that the rebase occurs at the timestamp of the addition, so that the note was added before the B changeset was submitted.

Branching makes a very important operation in the dbugt because it allows users to work independently (and often times exclusivly) on a bug in situations where two developers might have different approaches to a problem, or even in situations where developers feel that a bug was closed without actually being resolved appropriately they can simply branch the bug and work on it themselves without creating a change war. Merge strartegies are highly interactive attempting to rebase as much pertinent information onto the other branches as possible.

Of course branching is not always desireable and certainly something that needs to be reversable so changes made on a branch can be merged into the master branch either entirely or interactivly, and the merging branch will be removed. This would be useful in situations where a bug had been branched and one of the developers resolved the bug and commited a fix, a developer could easily merge their branch back into the resolving branch so that information that was accumulated in their branch that had not already been rebased could be made public record on the unified bug report.

Another situation where merging is useful is for duplicate bug reports:

 Bug_1-change1--change2
/                     \
*                      \
\                       \
 Bug_2-change1-change2---*-change3

Here we have two bugs both of which have had changes made to them beyond the initial operations, Bug_1 had a change in its seocnd changeset which marked it a duplicate of Bug_2, at which point dbugt merged change1 and change2 into bug_2. Conflicts were either overridden, discarded or branched based on user input.