Versioning and persistence

[Scott L. Burson]

   From: Chris Bitmead uid <chris.bitmead@alcatel.com.au> (x22068)
   Date: Wed, 21 May 1997 13:40:47 +1000

   >That's true.  I don't understand the point you're making, however.  The point
   >I was trying to make is that if you do it this way, you don't have to think
   >about versioning on every object access, which you were pointing out would be
   >silly.

   The point is that you would have a problem deciding how far to split
   up your system in order to get some advantage out of it. If you split
   too much how do keep the higher levels together? If not enough, how do
   you get enough grain?

   Basicly I think you were suggesting a system where you divide up the
   system in a certain way into segments, and I'm questioning if that
   gives you flexibility.

It's true that you lose a bit of flexibility.  If two objects are in the same
segment, they will always be committed (new versions will be created) at the
same time.

But this doesn't mean you can't work with different versions of objects on a
fine-grained level.  I can (in theory :-) open version 1 of a segment,
navigate down to a particular object, then open v2 of the same segment,
navigate to the corresponding object, and then compare them, or whatever I
want to do with them.

I'm not saying I know exactly how to implement this, but so far, at least, it
looks workable to me.

-- Scott