Re: [zzdev] versioning & cell copying

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuomas Lukka wrote:
> On Thu, 17 Aug 2000, Benjamin Fallenstein wrote:
> > Tuomas Lukka wrote:
> > > 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.

Oh! I thought d.version would do the job of d.cell-version. So what does
d.version do? Connecting to the last cell that was changed in the whole
space? If yes, you're running into problems with that, you know. Two of
the most primitive actions -- make link and break link -- change two
cells at the same time, and if you are deleting versions, so that the
versions before and after get next to each other, more cells may be
changed at the same time.

Have d..version-set with all cells which are changed from the previous
version to this version? But simply looking on d.version wouldn't
suffice then; a go-to-headcell on d..version-set would be necessary.

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

Good point. That system's both easy-to-use and often useful. -- On the
other hand, we should have the seperate "version views" as well: they
enable us to see a list of the changes that have taken place. 

And we should have custom selection of the area to version (not limited
to the standard what-this-view-shows). Cases where we want this:

- We want to see the last change to this document, which spans about
three hundred screens.
- What did these two commentary cells look like earlier? The way I'm
viewing them right now, there are about a hundred other cells on the
screen. (The solution, of course, is marking them and then execute "go
back to last version of marked cells.")
- I have no idea which parameter cells are needed to create this text
cloud item. (Positioning etc.) But I would like to see the last version
of it (or yesterday's version of it, or something).

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

Hmmmm -- okay, I think the concept has changed here when I wasn't
looking, so it probably is not good to use the old word for it any more.
I started with OSMIC branching: in OSMIC, a document branches when a
change is made to an older version. So the branch is *always* a change
of the older version. There is no need for an intermediate which is
"still the same."

In ZZ, there is this need, because we would branch the whole space
(which we don't want) if we wouldn't disconnect the branched cells from
the non-branched cells first. So, here we have a new beast, that subset
of the original's connections, which needs to be created before changes
can be applied, which can be sent to other zzspaces, which is a "copy
transclusion," etc. Only if this beast is *changed*, then, we can call
it a "branch." How are we going to call it before that?

The basic purpose is to "pull" (or "transcopy") a number of cells out of
a version or a space. The nice additional property is that if we have a
number of these coming from the same cell version, we can "add them up."
-- Unfortunately, the first appropriate German word that came to mind
turned out to be "patch" when translated to English. *g*

What about calling it a pull-out? And the CHANGE of a pull-out (often
creating the pull-out in the first place) is a branch.

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

As ABBA says: I do, I do, I do, I do, I do... :) Good luck!

BTW, the deadline for my applitude has vaporized: I have to postpone my
course half a year. :( It has turned out that the commission at my
school controlling general education math courses does exist, although
everybody thought they had ceased to exist: they just haven't talked for
five years, because since then there haven't been any new courses they
had to approve of. (In theory, we're an experimental school developing
new courses. Well...)

At least I'll have time to do this right, paying attention to the many
issues that are related to this. And get the level raster right...

- Benja