#8: Versioning

In the eyes of a lot of users a major drawback of Plone is the missing "versioning" feature. This is especially true for intranet deployments and document management based on Plone.

Versioning is a core feature of many CMS, and should be in Plone core, not as an "add-on", it should require a minumum effort from users to be used.

Summary

Plone needs to have a consistent, core solution for simple versioning tasks. This is expected of modern CMS packages. This PLIP outlines the needs and a proposed solution for versioning. Another PLIP will cover staging and multisite usage.

Status

This PLIP is very old, but its content still valid. CMFEditions looks set to become the standard versioning solution, but it needs help to get polished off and out the door.

Background

There have been numerous efforts in Plone and Zope over the years to accomplish versioning. This feature is badly needed for being competitive in the CMS market, especially for intranets and document management.

Many years ago, ZC published a specification for version control in Zope, written by Brian Lloyd. This specification had some implementation in a Zope product called Zope Version Control (ZVC). This ZVC repository product is the most well-known, but as it did not gain CMF integration, it has been mostly ignored (update: CMFEditions uses ZVC as a back-end!). At the first castle sprint, versioning was a hot topic. One group wanted an immediate solution to the painful problem of, "to edit something that is published I have to remove it from public view". Another group wanted to focus on the workspace approaches popular in high-end CMS products.

CMFStaging and CMFEditions grew out of these discussions. A significant PLIP was written, describing this work and approach. However, the project did not gain enough momentum to move forward. In 2004, Zope Europe worked with Oxfam on a project that required both versioning in a CMS, and publishing to multiple sites. An initial effort on this project had other parts in scope, including workflow state and translations. These requirements and the implementation proved too abstract and early, and the project went back to looking at CMFEditions and ZVC. Enfold and others had a sprint in October 2004 to discuss versioning. One of the primary needs was a pluggable storage model. This sprint tried to keep its efforts synchronized with the CMFEditions effort, in order to aggregate momentum into one solution.

The Oxfam project finished its primary work on CMFEditions in Feb 2005 and reached a point where the core features were implemented. This PLIP tries to capture that experience and propose a common versioning story for Plone.

Goals

o Work safely. If you make a mistake, you can go back to an

earlier version.

o Support publishing.

You can publish a version via workflow, but continue working on a different version in private.

UPDATE:  It has since been recognised that this is more of a staging problem than a versioning one. Some discussion has been conducted about using CMFEditions as a possible way of implementing "in-place" staging where transparent working copies are made available pre-publication. There are a number of difficulties around this, and most people feel that the other versioning use cases should be implemented first. Please refer to plone-developers for recent discussions about this problem. In particular, Martin Aspeli and Alec Mitchell have further details on this problem and ways in which it could be approached.

o Collaboration.

Version comments and version history help you communicate to co-workers the high-level changes during a document's lifecycle.

o Comparison.

Easily see how a document has changed between versions.

o Stable repository.

Authoritative version information is stored in a solid, pluggable repository.

o Archetypes friendly.

Custom content types should just work, anticipating special needs such as relations.

o Stable.

Don't rely on too much machinery and infrastructure that isn't already being used.

Use Cases

All versioning activities are performed through the Versioning action ('Versions') which is accessible only when the content is editable and only to those who can modify the content. The content owner - view and sort the versions history (version number, date, user, state, comment) - save as a new version the author (owner) explicitly chooses when to save the document as a new version, adding a comment. - browse versions The author (owner) can view previous versions, and see the previous published versions of the documen, if any. - compare versions the author can compare versions of a content selecting two arbitrary versions of it. If more or less that two versions are selected an error message is returned. - roll back version the author can roll back to a version of a content to an arbitrary one.

We could split the implementation in three main parts

1 Front end / UI (comments on usability are welcome)

As shown in the use cases, the number of action a user is allowed to do is very limited so the UI could be very clean, simple and usable. As shown un the screenshot, on each versionable content there will be an "versions" action which gives access to the versioning functionalities. In that page will be possible to create a new version, adding comments. It will also be possible to browse and comapre the different versions. Some usability problems related to the browsing has to be addressed, to avoid switching the context in which the user is everytime he wants to take a look at a previous version.

2 Versioniong  tool

A versioning tool is needed to define the versioning and diffing policy for the different content types. While for the user create a new version is a simple operation, it hides some implicit assumptions made by the site administrator or by the developer of the vesioned content type. In fact to version a content may differ by content type to content type. Versioning a folderish object like a complex article with images may be different by versioning a simple folder or a news. If you version a complex article you may want to make a snapshot of the main object and also of all the contained items. This may not be tru if you want to version a simple folder. If you version a news which refers a document you may want to version exaclty the version of the content you have in that moment, or you may want to refer the most recent version. Something similiar happens with the diffing, for each content type it should be possible to define a set of attributes which are interesting for the compare operations. The versioning tool will manage the configurations

content-type -> versioning policy

content-type -> diffiing policy

3 Pluggable backend

There are many different possible backend usable to store versions of contents, ZopeVersionControl(ZVC), CVS, Subversion(SVN), RDBMS, etc. Except for ZVC python layer has to be implented in order to make interact those backend with Plone. The versioning tool will define an interface to talk with the different layers.

Scope

o Not workspaces. Some CMS systems allow different people to work

in isolation, using a workspaces and checkout approach. CMFEditions does not provide for this. There can only be one active revision of an object in a Plone site.

o Not the published/private solution. Because you can only have

one active revision in a Plone site, you can't have a published/public version while another version is being edited. Another product (PloneMultisite, covered by another PLIP) will allow easy copying of content from an internal Plone instance to an external Plone instance. Having multiple versions impacts numerous other parts of the Plone architecture, and thus, has been deferred.

o Not tags or branches. This is only simple, linear versioning of

single items. This is not a system for labeling whole trees of content and reverting back to that label later. Nor is it multi-path branching of single items.

o Autoversioning.

It is possible to have a system where authorsdon't explicity create new versions. Instead, new versions are tied to saving or to workflow changes. This can be done with this architecture (and once was), but CMFEditions doesn't behave that way out-of-the-box.

To this end I (alecm) am creating a branch (alecm-versioning_policies) to add a way to associate versioning policies with particular content types (UPDATE: This has since been merged to trunk). The only inital policy will be one which creates versions automatically on edit for AT objects by adding a portal_formcontroller hook after AT's verify_integrity script, and a customized edit_macros to provide a Version Comment field for objects with the policy enabled. The portal_repository will allow policies to be registered and associated with specific contetn_types. At present the policy definitions themselves provide no functionality only a marker so that an object, script, or template can determine how to behave.

Risks

o Scope creep.

But of course, that's always hard.

o Diff is hard.

Getting a true diff on changes in HTML and property changes is harder than it sounds. CMFDiffTool may be useful in this regard, and more information will be provided here as potential CMFDiffTool/CMFEditions integration is further explored.