[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
- To: Benjamin Fallenstein <b.fallenstein@xxxxxx>
- Subject: Re: Versioning
- From: Tuomas Lukka <lukka@xxxxxxxxxxx>
- Date: Sun, 6 Aug 2000 22:33:17 +0300 (EETDST)
- Cc: zzdev@xxxxxxxxxx
- In-reply-to: <398D7D14.BF3DAA1D@xxxxxx>
On Sun, 6 Aug 2000, Benjamin Fallenstein wrote:
> Tuomas Lukka wrote:
> > Oh, and this new file didn't make it into your patch, apparently. cvs diff
> > only diffs files in if you've done "cvs add" on them and even then you
> > must use a special option.
> > How I wait for the day when these troubles are behind us, and ZZ takes
> > care of all this ;) ;)
> Well, once we have editing client/server and a storage supporting
> versioning, that's not so far off, is it? (Not that these two would be
> trivial, but if you consider the benefits for gZZ development, they're
> worth paying some thought.) By the way, versioning is *the* way to debug
> cellular programs -- just think of the possibilities! ;) CLang should
> always use the abstract ZZCursor, not ZZCursorVirtual, so that you can
> switch into debugging mode (requiring structural cursors) easily.
Well, that's exactly the reason for there being that base class ;)
> By the way, has anyone paid real attention to the problems of versioning
> in ZigZag? I mean, if you don't have some form of local versioning
> (traversing only the changes of a cluster or clump of cells), you're
> lost... on the other hand, a good versioning system could be the
> backbone for copying cells (as opposed to cloning them, where changes to
> one clone change the other clone), with being able to track the copying
> back and intercompare versions; also of global ZZ cell exchange, where
> one person receives cells from another person and changes them, and the
> connection to the originating space is still kept; and different
> versions can be merged under the user's control, so that applitudes can
> be upgraded with custom additions being kept. Although it seems slicing
> is supposed to to that job. -- So, are there versioning specs or something?
Unfortunately, no. The current code does a lot of wrk to be
versioning-friendly: changes are appended and working from this state to a
state where you can get any state of the space previously is not at all
difficult. The difficulty is that speccing the interactions of
is VERY difficult. This is one of the things I hope to work on with Ted
when he comes to Finland (next saturday, until september).
Your ideas on these interactions would be most valued.
I agree that this is one of the most important pieces: once this is done,
the rest is basically polishing performance and views.