[RFC] Cherry-picking, reordering revisions and 2D versioning

[Denys Duchier]

John A Meinel <john at arbash-meinel.com> writes:

> I am not 100% sure of this. The problem is that you need a way to
> declare that specific lines were generated from a given revision. In the
> current weave format, that means you declare that revision to be an
> ancestor of the current revision, and don't mark them as deleted. With
> the current weaves, only lines from your ancestors can be inside your
> current text, and there is no way to include non-continuation ancestry.
> (To say that FOO is an ancestor, but the ancestors of FOO are not).

I am no expert, far from it, but here are a few thoughts on this issue:

A revision really has a dual personality:

  1. it is a point in the history of a branch and as such represents an
    accumulation of changes

  2. it represents a specific change and as such serves as the "origin" of the
    new lines it contributes

personality 1 is what we use when we compute the set of "inclusions"
corresponding to a specific revision.  personality 2 is what we would like to
use for cherrypicking.

The problem is that we use a notion of "parents" (and the partial order induced
by it) to concisely represent inclusions: so if A is a parent of B, then B
inherits all inclusions of A.  That's not sufficient to support cherrypicking.

The partial order among revisions tries to serve too many purposes, among which:

  - how to compute the inclusions for each revision
  - how to find "join" points that can serve as good basis for 3-merge

I don't know if it would work, but I can imagine something a bit more flexible:

  i B1 B2

would contnue to mean to union the inclusions and also represents a "join" point

  i B1 +R

would be a cherrypick that just adds revision R to the inclusions from B1

  i B1 B2 -R

would be a cherrydiscard that basically unions the inclusions from B1 and B2,
except for revision R.

Cheers,

--Denys