A simple solution to this might be to just store the revision number of each child object in the stored revision of the parent object. So if you had three objects, two of which shared a child, like this:
A (revision 4) child C B (revision 2) child C C (revision 5) (previous revisions removed for clarity) Then A got changed, you would have this: A (revision 5) child C A (revision 4) child C (revision 5) B (revision 2) child C C (revision 5) If no revision specifier exists, the latest version is assumed. Then, if C gets updated, B will correctly point to the latest version, but the integrety of A will remain as it will still point to its older version. (You could also have a flag or an option or a built-in-metaobject-behavior or something that specifies that certain children *always* point to the latest object instead of remembering their versions at the time of parent-versioning.) This way, you don't have to keep unnecessary copies around as long as the children are already versioned. -Ken ----- Original Message ----- From: "Reed Hedges" <[EMAIL PROTECTED]> To: "VOS Discussion" <[email protected]> Sent: Wednesday, May 09, 2007 5:07 AM Subject: Re: [vos-d] delineation and revision control > > Yes, only some things would be versioned, or have different policies as > Lalo suggests. > > Yes, child linking has to be preserved correctly. I think we can > basically take an object's child list as part of its state. When you > make a new version you might change those, or copy them whole from the > original. In your example, the texture belongs to both I guess, but > really, both objects have links/references to some objects, that it > just happens to be the same one can be looked over for the most part I > think. > > Reed > > > > On Wed, May 09, 2007 at 11:45:50AM +0200, Karsten Otto wrote: > > Well, Lars' suggestion of versioning only "interesting" parts and > > your suggestion of horizons seem reasonable, but I don't think we > > have the basis for this in VOS. A vobject usually cannot live as > > isolated entity, but *requires* a number of relations to child > > vobjects to make sense; thus any user-percievable "world object" is > > actually a subgraph of the overall world graph. > > > > The problem is delineation: It is not clear which subgraphs represent > > independent "world objects", or if there is even a distinctive > > decomposition. For example, two objecs may share a texture - which > > vobject does it "belong" to? If you change one vobject, do you > > include the texture in the version? Where do you stop following > > relational links? I don't recall if there is any prohibition in VOS > > against cycles in the graph - I think there isn't - so matters become > > even more complicated. > > > > The only separation I currently see in VOS is the relation between > > the site vobject and its children, but even here it is not clear > > which children represent aspects of the site itself, which are > > scenery, and which are avatars. > > > > Any suggestions? > > > > Regards, > > Karsten Otto (kao) > > > > > > _______________________________________________ > > vos-d mailing list > > [email protected] > > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d > > _______________________________________________ > vos-d mailing list > [email protected] > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d > _______________________________________________ vos-d mailing list [email protected] http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
