Ahh, you want LODs. And they neatly solve the problem you described.
And a bunch of others. Think of a LOD as a revision history graph.
Imagine being able to create a new, empty (or partially populated)
"container". That container is a LOD. You can do set operations from
one LOD to the other. They are a lot like branches except that they
themselves can branch & merge.
The way that we'd do what you wanted is you'd create a new LOD,
stick B, C, D, E into it, and make it the default LOD in your
repository.
LODs have some very nice attributes - each change is a set element, the
LOD is nothing more than a recorded history of what set elements are in
this LOD, and you can cherry pick from one LOD to the other. Out of
order, sparsely, whatever.
The only restriction is that you have to have all the changes in your
graph. There is no concept of a sparse graph. You can trim off stuff
that happens after some point but you can't remove points in the middle,
even if they are in the other LOD. Is that OK?
Linus first sounded like he'd accept this as an answer and then later it
fell out of favor because even though he could hide a bad changeset in
another LOD, he didn't want it in the graph at all. I don't know how
to do that.
The other gotcha is that LODs are only partially implemented and are
going to stay that way until we achieve concensus on how BK should
work for you.
----- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - 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/