[Zope] versions - actual usage

[Hung Jung Lu]

morto-@dennisinter.com (damian morton) wrote:

>	Would using versions to 'archive' past issues be a bad use of versions? Is
>this actually possible?

In my opinion, Zope's versioning device is not suitable
for 'archiving' past issues. Zope's versioning device
is more for a team of programmers/content-managers
working together. It is dangerous to use it to keep
past issues, because someone might hit the commit button
accidentally and then the old version is gone.

>	Is there a way to create a partial version, for example one restricted to 
>a
>part of a tree?

Zope's versioning device is OK for this purpose. It does not
actually limit the user to version a branch of the tree, but
in practice a good discipline usually means the versioning
device affects only a branch of the hierarchy tree.

>	Is there a way to create a version within a version?

No, Zope's versioning device is not good for this.

>	Where multiple people are working on a site, is it best for each person to
>be working in their own version, or is it best for each section of a site 
>to
>have its own version, or should their be one version which everyone works
>in? Whats the best way to leverage the facility of having multiple 
>versions?

My opinion for your site is this: your site is content-intensive.
So, I would suggest you keep contents in local file system instead
of keep them inside Zope's ZODB. The directory structure should
reflect the release date structure of your magazine.

In my own experience, Zope's versioning device is for multiple
programmers to work on their own piece of code, without making
the system unstable and thus affecting other programmers that
are working on some other part of the system. So, in practice,
you will have several versioning devices active at the same
time. Versioning device also allows programmers to see what
files are being worked on by what people. This way, you don't
need to worry two people working on the same file and destroying
each other's changes.

In your case, you can still use the above scheme. But if we
are talking about preparing the next issue of the on-line
magazine, I would suggest this:

(1) Create a folder for the next issue you will be working on.
    (This does not need to be the whole magazine, it could
    be just one part of the magazine. You create as many
    folders as you deem necessary.)

(2) Use Zope's user management and create user/password for
    the folder, so outsiders won't be able to see the new
    version. Or you can use cookies or other devices to
    make the new issue invisible to outsiders.

(3) Have a page containing index_html that does something like
    the following:

    <dtml-if "REQUEST.has_key('AlanWorkingOnMarchEdition')">
      <dtml-call "RESPONSE.redirect(MarchEdition.absolute_url())">
    <dtml-else>
      <dtml-call "RESPONSE.redirect(FebruaryEdition.absolute_url())">
    </dtml-if>

If you want to keep a permanent archive of past issues,
you have to implement a lot of indirections inside Zope
to ensure that newer issues don't conflict with old
issues. In practice this is very very hard to achieve,
especially if you want to use all the features of Zope
(external methods, database connection, contents from
file system, etc.) You have to decide up-front what you
define as an "issue" of your magazine. Many websites
nowadays change from one minute to another, so it's
virtually impossible to archive an "issue" without losing
some information. If you are serious about archiving
a past issue in its total integrity, you need more than
just one Zope, if not more than one machine. In my
opinion, that's not the way to go nowadays: websites
are becoming more and more interactive, and the concept
of "issue" is murkier and murkier. If you have some
static pages you want to archive, probably you can
get by just by using mirroring programs like wget
(in Unix) or other shareware programs in Windows
(search in www.shareware.com, www.download.com, etc.)
and grab a snapshot of your whole website, then burn a
CD and call it done. :) Of course, if you have
more interactive elements (form inputs), you will be
very miserable trying to keep the whole version...
the best thing in that case would be freezing the
entire Zope site (your whole Zope folder, with all
external methods, database files, local file system
content files, etc.), possibly into a CD, too.

Anyway, you have to decide where to cut the cake.
There are trade-offs between:
  - interactibility
  - dynamic content / static content
  - time
  - money
  - earthquakes, fires, or other natural disasters
  - lawsuits or other unnatural disasters

No one else can cut your cake except yourself. :)
But Zope's versioning device will only play a
very tiny role, that's for sure.

regards,

Hung Jung


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com