I think it would be worthwhile continuing to work on this but I think we
need to sort out some of the issues mentioned below before we switch
over so any committer can update the site without requiring assistance
from Infra or yourself. I also agree with Matt's comment about it being
preferable to be able to make changes to the site but not have the
changes go live instantly.
A bit off topic, do you know of any tools to edit pages offline (where
you can have a WYSIWYG view of the page) other than installing a
confluence server on my notebook?
Thanks,
John
Jason Dillon wrote:
On Jul 26, 2006, at 8:52 AM, Hernan Cunico wrote:
Confluence uses it's own versioning to manage the history changes to
"confluence" pages, AFAIK confluence does not support SVN yet. For
the cwiki we use the "autoexport" plugin to get the confluence
content automatically exported into HTML format and via a template we
customize the look & feel of those exported pages.
I believe it to be highly unlikely that Confluence will natively
support SVN for versioning... ever. I did however implement a
prototype of a plugin that would commit changes to wiki pages to
SVN... but never really finished it.
The exported pages are independent from confluence version control,
if we use a different version control we will not get the exported
HTML in sync with the actual (and versioned) confluence content.
Rolling back changes will be a nightmare. We need to find out a way
to get those two in sync.
I believe we can solve this problem easily. First, when you rollback
a page in Confluence, then AutoExport will rebuild the static page
based on the new version... so they are in sync in some degree. For
most types of rollbacks the Confluence mechanism should be used.
Probably we want to include some comments in the generated pages (via
the vsl template) to include the path in Confluence, the page version
number and who changed it. Then, if we did rsync to SVN to publish
then we have the required details to know how to roll the change back
from Confluence. This should be trivial.
We could also implement a SVN tag for each push, which would make it
easier to quickly rollback the site if something major happened...
granted it would be a bit of work to get Confluence back in sync.
But, with the above comments, and the tag, we could easily disable the
automatic sync and revert pages to the correct version (based on the
comments in last known good tag).
Or, if I finish my SVN plugin, then we could just re-import the entire
space from a specific revision number.
Lots of options.
The plugin has some issues/limitations that still need to be
addressed, it even has it's own JIRA
(http://could.it/autoexport/index.html). Some of those issues will
not let us serve the HTML from a different location, well at least
not totally.
We may want to add an additional massaging of the content, where we
can fix any limitations that AutoExport has...
Or we could fix AutoExport to better suite our needs.
Or both.
Security seems to be an easy thing to manage as we can restrict
access by users and groups in terms of confluence, but we will not
have access to the actual autoexported HTML content. If we need to
delete any content from the autoexported directories we will not be
able to do it ourselves, just the infrastructure folks have access to
the FS.
I'm going to see if infra@ will let a few of us have access to it, so
that I can better help admin the Confluence install.
But... the AutoExport plugin should really have a mechanism to clean +
publish... which should be easy to add.
--jason
