I wonder if we could go back to running our own Confluence server in
our zone... but only to serve as the editing platform... so we could
install the plugins we want and implement the procedure we need to
sync up to the "real" website.
That... and its a bit safer in that someone won't nuke all of our
content when then accidentally import a different install (not just a
space export).
And it would make it easier for use to backup too... since right new
we are getting timeouts when exporting that Hernan was talking about.
--jason
On Aug 4, 2006, at 6:59 PM, Matt Hogstrom wrote:
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
