Version Numbers

[Jecel Mattos de Assumpcao Jr.]

On Thu, 4 May 1995 11:40:43 +0200 rainer@physik3.gwdg.de (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
would work.

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

-- Jecel