It is important to understand the concept of operation behind versioning in order to
know what happens in implementation. The documentation goes into the details,
but the key thing to keep in mind is that versions are not the important part of the
versioning model -- states are. Versions are only important because they give a
name to a state.
When you look at the tables in your database, you'll see that INSERTs are done in
the "adds" table, and DELETEs are implemented as inserts to the "deletes" table.
UPDATEs are implemented as inserts to *both* the adds and deletes tables.
Even if all edits are done to the version named "DEFAULT", the same insert-only
methodology is used, with the states progressing, and the DEFAULT version
advancing to the most recent state.
Now, if your state tree is just a long chain of edits without branches, then the
reconciliation process will not find any conflicts, and posting is not necessary.
You will, however, still need to compress the table to purge the adds and
deletes tables of the state changes, and publish the edits into the base table.
The only exception to this is when you've requested the "move edits to base"
option, which rolls the reconcile/post and compress into the edit operation.
Of course, if you never use the features of versioned editing, then shifting
to unversioned editing (with only short transactions) might be more efficient.
- V
