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
>
>
>
>
|