Very nice Jason...like Dain asked...is there anything he can do :)
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
