Jecel Mattos de Assumpcao Jr.
Fri, 5 May 1995 22:21:54 -0300
On Thu, 4 May 1995 11:40:43 +0200 email@example.com (Rainer Blome) wrote:
> Again, if we had what we wanted (i.e. an OO system), it'd be trivial:
> o Every versioned object (preferrably down to single methods) maintains
> an (RCS-like) version-number of itself.
Ok. This is pretty easy in Self 4.0 - each object can have several
annotations ( not the same thing as Faré means by the term ) and the
version could be one of them.
> o This number changes (like in RCS) when the owner (locker) of that
> object decides to take a snapshot of the current state (i.e. the versions
> of the components).
I am not sure who this owner is in the style of version management that
we are talking about here. Would it be a user or the object which
"contains" the object being snapshotted ( there is a neat word ;-)
> o Branching and creating sets of versions with permutations of
> orthogonal features (versions/snapshots of components) is equivalent to
> cloning and modifying. RCS already allows arbitrary names for
> snapshots, but they should be in addition to numbers.
Cloning and modifying is certainly a way to have several "current versions"
at the same time. Sharing complicates this as the rest of the system
could not try out the new version - it would still point to the original.
> o Since this scheme is object-based, it is just as file-based and
> hierarchichal as the objects are, which is what you'd expect.
Objects aren't a hierarchy like Tunes is. They form a graph with
shared nodes. That is why it is not clear to me how all of this
> Multi-user access will surely complicate things, but that seems inevitable
> to me.
*That* is the one problem that doesn't worry me. I am pretty satified
with the simple multi-user semantics I have adopted for Merlin ( I think
I have already described this here, but can do it again if there is