[Zope-CMF] Revisions & CMF

[Shane Hathaway]

On Thu, 31 May 2001, Toby Dickenson wrote:

> On Wed, 30 May 2001 11:04:49 -0400, Shane Hathaway
> <shane@digicool.com> wrote:
>
> >A lot of the ideas presented are actually more alike than it sounds at
> >first.  A future version of a document is really the same as a CVS
> >"branch".  No, we might not need diffs and merges, but we do need the
> >concepts that are fundamental to CVS.
> >
> >A Zope "Version" object is also equivalent to a CVS branch.  However,
> >FileStorage, the default implementation of the ZODB storage layer, is
> >currently hardwired to disallow concurrent branches.  I don't know
> >whether BSDDB3 storage makes the same assumption.
>
> An observation, and Im not sure whether or not it is obvious....
>
> You cant allow concurrent branches without some CVS-alike diffs and
> merges. (unless your branches will forever remain separate)

That's basically true.  I was thinking of implementing a lower quality of
service where branches would just stomp on the trunk when merged, but the
workflow would enforce a policy that makes it impossible to change the
published copy so it wouldn't matter.

Tres has been advocating a different way to look at this and I'm coming to
see the advantages.  If we could just "tag" specific revisions of a
document and have those revisions show up as the published version, we'd
provide what everyone seems to be asking for.  No concurrency involved.

Now, modifying that idea a bit, Zope versions could provide this kind of
behavior.  If there are only two possible tags, "published" and "future",
then "future" is just like a Zope version.  Zope versions are hardwired to
prevent concurrent modifications.  Each object would have its own logical
version.  We could provide access to the future version via URL rather
than a cookie.

I suppose the principles of Extreme Programming would say this is the
right thing to do--it provides exactly what is asked for and nothing more,
it has a minimal impact on the codebase, and it would be reliable.

Shane