CMS 2005: Lazy Version Control
In a multi-user system, a problem can
arise when two or more users edit the same document simultaneously. This is
known as the “lost update” problem, and occurs when, for example, user A opens
a document, and user B opens the same document, such that the last user to save
their copy of the document overwrites the changes that have been made by the
other user. The traditional approach taken by content management solutions to
prevent this problem has been to force users to checkout documents when they
wish to edit them, and then check them back in when they have finished.
System 7 CMS, however, does not use this
approach for a number of reasons. Firstly, studies of its application in
practice clearly show that it generates problems of its own, for example where
users checkout content, and then absent-mindedly forget to check it back in,
forcing other users to find the errant user or seek the assistance of an
administrator. Secondly, studies also show that in practice, situations where
simultaneous editing of content would occur are quite rare, and number does not
justify the productivity overhead generated by check-in/check-out systems.
For the purposes of maximizing productivity,
convenience and optimizing user experience, System 7 CMS instead uses a system
called “lazy version control”. Whenever a user begins editing a content item,
their copy is automatically moved to a “temporary editing area” (with the
purpose of preventing the creation of a new version on every minor change and
providing continuity between Web sessions). When the users finishes editing the
content, before it is copied back from the temporary area the system checks
that the original copy has not been changed since editing began.
If the original document has changed
since editing began, the system notifies the user and prompts them to either
cancel the save operation or overwrite the changes made by another user and the
user examines the original document and merges the changes prior to saving
again. In most publishing applications this happens so rarely that the case for
removing the check-in/check-out overhead is overwhelming. However, using a
special optional “content locking” feature, publishers can also implement a
check-in/check-out process if they desire.