You are lost because no such simple order exists.
You're trying to force a partially ordered set (BK changesets) into a
strictly ordered set (CVS-like thing), and you can't do it.
Assuming a static BK tree, you can always find _one_ ordering that will
work. But when the next merge comes around, you'll notice that you may
well have to re-order. You can never get it right.
The fact is, a BK tree is fundamentally more powerful than a linear CVS
tree. If you want to get the BK information into CVS, you have to
either:
- throw away information (every time I do a merge, you commit all the
new code as one patch or possibly a set of "linearized" patches at
the top-of-tree)
- you use a CVS branch/merge to emulate every non-linear BK event (and
you'll probably have to rebuild the whole CVS tree every time a merge
occurs)
>Also note that the fact changesets can be merged in the past, and not
>alwayas in the head
No. ChangeSets _cannot_ be merged in the past. ChangeSet's can be
_based_ on past events, and have times in the past, and be merged
through a to the top of tree.
I don't think you can emulate this in CVS easily, since the branch has
to be "pre-created" in the CVS repository (when it was HEAD), I don't
think you can go back and create a branch "in the past" to graft onto.
Which is why I think you have to recreate the whole CVS tree (and insert
the branch point at the right point) when this happens in order to
really get the full BK information.
So please realize that BK is different from (and strictly more powerful
than) CVS. But this difference is the whole _point_ of it, and the
reason for why I use it for the kernel, and refuse to use CVS.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/