Re: [zzdev] versioning & cell copying

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuomas Lukka wrote:
> 2. cell-version and content-version: two things: 1. these are easy to
> provide as well as something that Ted wants

Well, I'm not gonna complain then. It would just have been nice only to
need one system here...

> 2. making the operation "jump to previous version" is easy
> using these: you go through al the shown cells an see whose previous
> cell-version is the latest. This steps nicely through a group of cells
> (the view will change).

They aren't necessary for this -- I mean, usually you will want to jump
to the last change, not to the last content or connection change, and if
you want, ignoring impertinent changes is a non-brainer.

> 3. custom dimension vs custom view: if possible, a custom dimension is
> preferable because you can use that with any view but custom view is the
> only view like that.

Hey, wait! Don't limit yourself like that. Of course every view should
be usable. A custom dimension may be nice for some things, but the more
advanced stuff SHOULD BE THERE, and usable with ANY view. So we gonna
need the hooks anyway.

Both showing older versions (and branching them), and selecting older
versions does have to be something you can do with every raster.

> 4. version-alt and headcells: I think that a tree with d.version and
> d.version-clone could be useful - I may not have understood exactly what
> you meant.

d..version-clone is of course another way to see it. My naming was
focused on branching, seeing a branch as an "alternative version."

Headcells: Let me put it this way. You are branching, say, 100 cells.
This branching "copies" them into the current space (if they're really
copied or if references are stored is a design decision). Now, it is
clear that we want to 1) retain all connections of these cells amongst
each other, and 2) break all connections with other cells. Why? Because
links are bi-directional, and keeping a link to a cell outside the
branched cluster means that we have to branch this cell, too.

Now, what is the relation of a cell's connections before and after the
branch? Either they've remained the same (if all connections are to
cells inside the cluster), or one or more have been broken. In this
case, the branch's connections are a subset of the connections of the
branched cell.

(Note that the cells aren't re-connected after branching or something:
Branching a cluster is one op, and happens at one versioning time.)

Which properties does the branched version have? First, its connections
are <= (same or a subset of) the connections of the original. Second,
when the branch is branched, the second branch's connections are <= the
connections of the original, because a <= b <= c implies a <= c.
Therefore, all unmodified branches of unmodified branches can be seen as
unmodified branches of the original. Third, if you have two branches of
the same original, you have two subsets of the original's connections;
as in the original's set of connections, there is only one connection
maximum in each direction along each dimension, in the two subsets there
also must be only one connection maximum. If you create the set of
connections in the first *and/or* the second branch, this set will again
be the original's set or a subset of it, thus in it, too, there can only
be one link in each dir.

Thus if you have multiple branches of the same cell, you can reconstruct
something *closer* to the original cell, if not the original cell
itself. And the original cell is just another name for the headcell on
d..version-alt, and each cell branch does have a negward connection on
d..version-alt (the headcell being its original).

> 5. I don't understand the non-conflict thing.

Uh, I think I already answered this. :) But I didn't clarify on its
purpose.

> We definitely do want cell
> exchange, and the versioning id and that seem to be related. However,
> isn't the usua mechanism for sending a cluster of cells making a slice out
> of it?

I don't know what the USUAL mechanism is -- but version branching makes
cell exchange a LOT easier. If Ted wants the slice system, fine; but *I*
want to use something that makes exchanging *versions* easy. Why?

First, Ted himself says: "ASSUME that the user can neatly divide the
world into slices." Consider this. If I'm sending the newest version of
my story project to a friend, it's easy to make a slice out of it; I do
not need to include all these personal notes I don't want others to see,
which are connected to the cells containing the story.

Now consider this. I'm not sending the story to my friend, I send it to
my editor. She will propose some changes and add some comments. Then,
she sends the whole stuff back to me, again. I get it as a slice.

Naturally, I want to compare the different versions and probably merge
them. How am I going to do this? Will the slice attach in place of my
version of the book? Will it attach somewhere else, so that I can have
one view for each of them? Both possibilities aren't satisfactory,
really.

Why not use our standard versioning tools for this?

We'll have thinkertoys to intercompare versions of everything we can
visualize in a view. Why not use them to intercompare stuff from
somewhere else?

With permascrolls and vstreams, we can intercompare two different
versions of the same fluid media document, see what remained the same,
see what changed. We can do this even if the two vstreams were edited
last by two different people, as long as the same permaddress is used
for the same permascroll contents. When we treat a cell cluster we send
to another zzspace as a version branch, we can do the same for zzcells,
because THE CONNECTION TO THE ORIGINATING SPACE REMAINS. This doesn't
mean the computers the spaces are on must have a network connection or
something. But when the cells are edited in the new space, and then send
back to the originating space, on disks or by eMail or any other way,
the old space can recognize them as its own (or rather, originating from
it), and it can see the connection to its own current branches of them.

This even works if in the new space, cells have been added and deleted,
and the new set in the new space is send back to the old space.
(Actually, you need to send the equivalent of a diff, but that should be
straight-forward; you just choose a number of versions you want to
include, possibly only the one from the originating space and the newest
one.)

A slice is more like putting the cells in a separate file which you
send. Oh, there are clever mechanisms to attach it to a space. Only that
these are completely unnecessary for my purposes here. A slice may be
nice for many things. (I still don't get many of its usages.) But for
sending a number of cells, editing them both in the originating and in
the send-to space, sending them back, and consolidating the versions is
no business for slices. (They don't do it well.) It's the business of a
holistic zz versioning system.

And better versioning should be part of where we're going, right?

I hope this clarifies a bit, or doesn't it?
- Benja