Re: [zzdev] versioning & cell copying

[Tuomas Lukka <lukka@xxxxxxxxxxx>]

On Thu, 17 Aug 2000, Benjamin Fallenstein wrote:

> 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.

I meant one of the dimensions is *either* connection or content, the other
is content only. So it gets narrower. I think I wasn't clear.
 
> > 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.

Yes. And that's what I mean by making them dimensions and easy-to-use
operations: what I suggested was looking at all the displayed flobs,
regardless of raster, and selecting the latest previous version. Does
exactly that.

> > 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).

Ah, multiple branches of the *SAME* cell. Now I understand what you meant,
I thought conflicts as in CVS.

> > 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?

Very good cases - I'll have to talk about these with Ted. Having solid
examples makes things so much easier to talk about. Yes, now I see why
sending a cluster of cells makes a lot of sense.. 

We've been having a very busy time here - tomorrow we're talking to our
funder from Sonera, and are now preparing demos; you can see from the
number of commits, maybe ;)

	Tuomas