stacking threads is not enough, how about a graph instead

[Vincent Ladeuil]

While making the test suite pass under python-2.6 for bzr I encounter a situation where loom, while helpful, didn't fully address my problem.

First, bzr selftest couldn't run until several *independent* problems were solved (say b1, b2, b3).
Once the test suite were running, there were also several independent problems do be solved (f1, f2, f3).

Ideally, it should possible to define that a thread is built on top of a merge of several *parallel* threads.

bzr show-loom will show something like:

  pass
        ^f1
        ^f2
        ^f3
  runs
        ^b1
        ^b2
        ^b3
=>bzr.dev

bzr.dev, runs and pass being the actual threads, while bn and fn being threads that are merged in their respective parents but with independent ancestries, the caret and the additional indentation showing the relations.

[Stephen Compall (scompall)]

For this last sleepless night, I took the opportunity to consider the implementation of a DAG of threads. For example, the approach to forward-merging threads involves choosing the *longest* paths in the DAG, minimizing the number of merges required.

The problem is diffing. With a stack of patches, the base is the down-thread, so diff has a definitive base revision to compare to. This is not so with parallel parents. All the conflict resolution information is contained within the thread itself, and cannot be automatically derived to determine which parts are conflict resolution between parents and which parts are changes due to the thread itself. This isn't a problem with stacks because the conflict resolution is guaranteed to be in the down-thread.

[Robert Collins (lifeless)]

Loom is an explicit experiment with simplifying the DAG that exists amongst branches; I'd like to really see some concrete use cases that the stack doesn't work for to consider this a valid bug.

@S11001001 I agree with you :)