"Version" Aversion

[Mark S. Miller <mark>]

I've been distinguising between "version", "state", and "copy".
"state" and "copy" are probably both able to be used clearly, but
having a different word for "version" may be clarifying.

"Version" corresponds to "Bert".  A given version of a document can
change its contents while still being the same version.  Therefore one
can refer to the "current experimental version" even though this is a
moving target.

"State" corresponds to "Stamp" (or perhaps "Orgl").  It is a
particular set of fixed contents of a document.  Editing a version
consists of changing which document state is the state of that
version.  (I.e. hopping the Bert to a new Stamp.)

"Copy" or "Replica" has to do with the storage media a given thing is
available on.  Even if a document (version or state) is replicated on
multiple machines, they are all still the same document (version or
state)--it just has a redundant implementation (and so has higher
availability).

Let's see if these distinctions work for the cases in your message.

   Date: Mon, 11 Dec 89 16:33:46 PST
   From: bobp (Bob Perez)

   ... Suppose that marcs 
   and bobp each have copies of the file on their individual computers.

   Most people would agree that "Xanadu Glossary" is the name of 
   "a document" whose identity is the conceptual work embodied in 
   the 2 individual copies owned by marcs and bobp. But most people 
   would also agree that the 2 copies are each separate documents, 
   and might even refer to them as "2 versions of the same document".

I would say that there is only one document here, but that it is
available from both marcs' and bobp's computers, even if they're not
connected.  In first product (and probably for a long time after) a
hopable Bert may not be replicated across machines--you have to freeze
a Bert to replicate it.  A hopable Bert has only one machine as its
true home.  You can inquire about the state of the Bert on other
machines, but this request either has to communicate back to the
original machine, or give you back stale information ("I don't know
where the Bert is now, but before it was at this Stamp...").

What we may do eventually (*way* after first product) is allow
replicated hoppable Berts and multi-machine hop operations.  This
would involve all the wierdnesses that the database community suffer
with to make distributed transactions work.  (It is already a lot of
work to do this both deadlock free and starvation free.  Doing it in
the abscence of inter-machine trust isn't a solved problem)
Fortunately we can avoid this wierdness for a *long* time.  (There is
also the issue of mutual writers of a Bert coordinating with each
other in their own way, but I won't get into that now.)

   Now suppose that marcs and bobp each start editing their copies 
   and wind up saving several new representations of their work 
   in progress. 

Not possible under the assumption I made above.  Perhaps they started
with replicated copies of the same Stamp instead of the same Bert.  Or
perhaps they forked off new Berts from a shared frozen Bert.  In
either case, it seems they now have two new Berts, and so two new
Versions.  This happens regardless of whether they are on the same or
different machines.

   Again, most people would refer to each successive 
   state during their respective editing as "different versions 
   of the same document" (and if they saved each of these successive 
   "versions", each such saved file would be called a separate "document"). 
   And so on...arrrrggghhh.

The saved states would be *state*s, not versions.  If someone creates
a new Bert to start editing starting at one of these states, then you
have a new version.

   Unfortunately, our technology focuses new spotlights on the problem 
   and will undoubtedly cause our markets some degree of confusion 
   as well. Because of this I believe that Xanadu should lead the 
   way in resolving the ambiguities, if possible.

I think we internally have an understanding in which these ambiguities
are resolved.  It will probably be quite a task to communicate this
understanding.  Perhaps the first step is to choose a term other than
"version" for the above concept.

   There are at least two different notions being confused here. 
   First, there's the distinction between horizontal versioning 
   (the 2 copies held by marcs and bobp) and vertical versioning 
   (represented by the successive states visited by marcs and bobp 
   in their respective work). 

Does your "horizontal versioning" correspond to my "replicated
copies"?  Does your "vertical versioning" correspond to my "state"s or
to my "versioning"?

   Second, there's the distinction between 
   global document identity (i.e., the conceptual "Xanadu Glossary") 
   and local document identity (e.g., bobp's "version" of "Xanadu 
   Glossary").

I'm not sure what you mean, but I have frequently found myself using
the term "document" to mean sort of the underlying platonic expression
which all the states and versions are approximations of.  For example,
we may refer to as the "Xanadu Glossary" document the cloud consisting
of all the different versions and states that we are trying to pull
together to create a Xanadu Glossary.  Now one can claim that we call
this by a single name because we have in mind the end result of this
process of pulling all this together.  However, I would guess that
there are many such clouds of versions that never do get pulled
together, and even some for which it is anticipated that it will not
get pulled together.  It is sort of like a globular cluster in which a
given document state is a position in state space, versions move in
state space as a result of being edited, and the "gravitational force"
is the incorporation of changes from one version into another,
bringing the two closer in state space.

In any case, this "cloud-document" is an emergent pattern which has no
direct recognition by the system.  In particular, there is no system
supported global identity of the cloud.  

   I've adopted the convention of using "global identity" to refer 
   to the conceptual work and "local identity" to refer to the identity 
   of a specific instance (the Bert).

It seems you do have a system supported global identity in mind.
Perhaps you figured that if it were replicated, each replica would
have its own BertID?

   It might make sense to propose new terminology for horizontal 
   versioning. For example, one might refer to different "prongs" 
   (to use a "forking" metaphor) or, if you prefer to think in terms 
   of trees, different "branches". Successive vertical states within 
   a prong/branch can probably continue to be thought of as different 
   "versions" (at least, that's the way I think of them).

   I know that there are version control systems (e.g., PVCS) that 
   use the term "branch" to refer to horizontal versioning. Are 
   there standards I should consult that I'm just unaware of, or 
   are the remaining ambiguities as bad as I think they are? Comments?

I know of no other set of standard terminology other than something
MarcS mentioned once (maybe PVCS?).

Have I understood the distinctions you were drawing, and have I mapped
them to our distinctions correctly?  (I fear not)

In any case, the ramifications of versioning sure are difficult to
think about (at least I find them so).  The only thing worse is the
combination of versioning and linking ;->