An Example

Here's a nice way of thinking that shows versions and instances in action. I came up with it early on, and found it very helpful. I'll explain the way of thinking by example, by seeing what happens to a file as it moves through a single editing cycle (open, edit, save, close).

I'm thinking, here, of a simple file, a file of which only one copy exists—in other words, an object that has only one instance, and hence only one version.

There could be older versions that are not extant, of course, but we don't care about them.

So, that's the initial situation.

The next step could happen in various ways. We might first decide to edit the file, thereby creating a growth point, and then open the file, creating an instance in memory; or we might already have the file open, for some other reason, and then decide to edit it. Or, if the file is one we edit regularly, the growth point might be said already to exist, in which case the first figure was incorrect. In any case, we reach the following situation.

Next, we edit the object … that is, we alter the single instance in memory so that it represents a new version.

Actually, it's not quite that simple. We probably alter the single instance a number of times, creating a whole series of new versions; in fact, if the editor has the ability to undo changes, we may well create a whole branched tree. We normally ignore all such intermediate versions, and that's a reasonable thing to do, because the versions aren't extant for very long.

It's also interesting to wonder about the validity of the intermediate versions. Suppose the object is a plan for how to divide up $100 among ten people—since one entry is edited before another, the intermediate versions won't add up correctly. Intermediate text documents won't contain complete or grammatical sentences; intermediate code won't even compile.

The idea of intermediate versions can be taken to extremes. Suppose the editor program represents the object using lists, and the lists are stored as linked lists of elements, plus, as a convenience, a computed field, the number of elements. Should we consider an intermediate version in which we're halfway through adding a new element to a list, and the list data structure is internally inconsistent? Should we then, every time the CPU writes to memory, consider the physical order in which the bit values inside the memory chips are updated?

But I digress. So, we've altered the single instance in memory to create a new version, and now we save the new version to disk.

At this point, there are no longer any instances of the original version, but, as I noted earlier, it's still OK to include it.

Finally, we close the file in the editor, and the instance in memory is destroyed.

Here are some other scenarios you can work out, if you're interested.

• What if there are successive editing cycles, or multiple saves in a single editing cycle?
• What if a new object is created in memory and saved?
• What if the object is stored not only on disk but also in a version control system? (By the way, version control is exactly the right name.)
• What if the object is replicated, i.e., has instances stored at several sites, with changes made at one site transmitted to the others at intervals?