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

[Robert Collins]

On Mon, 2006-01-16 at 16:54 +0100, Denys Duchier wrote:
> 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

This is indeed a duality. I've been thinking for a while about whether
we can break the datamodel into two:
* snapshots
* changes

Commits would then be implemented by
1) make a new snapshot
2) add a change record between the current snapshot and the new one.

This would allow a more direct and natural behaviour - you can state
that 'I have that change' OR 'I am derived from that snapshot'. Having a
change does not imply derivation from either of the endpoints, deriving
from a snapshot does.

There are a number of useful things this would give:

 * when two people have different views on a change, we can record them
both by recording two transitions with the same endpoints. (i.e. 'Merge
from mainline', and 'Merge in $foo work' are two common views on a
single transition)
 * doing multiple digital signatures and the like becomes easier because
one can attest to either the change, or the endpoint[s], or both -
letting more precise semantics arise naturally.
 * change specific caches or memoisation of data now has an explicit
place to hang from.

Rob


-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060118/f7c63311/attachment.pgp