[pmwiki-users] Re: How to 'automatically' keep a deployed PmWiki install up to date?

Crisp, Steve [UK] SCRISP at ngms.eu.com
Sun Sep 25 10:17:40 CDT 2005


On Fri, 23 Sep 2005, Crisp, Steve [UK] wrote:

>> http://www.pmwiki.org/wiki/Cookbook/InstallationTracking
>> 
>> Let me know your thoughts,

On Sun 25/09/2005 08:52, Christian Ridderström wrote:
 
>Have you thought of using CVS to simply update the installation?
>
>This is what I do for my pmwiki installations. There is no guarantee
>though that a new release of pmwiki won't break old recipes etc, so I'm
>not sure this is something you'd really like to do automatically...
>
>You should also consider wiki farms/fields in this context... that should
>reduce the n:o installations you need to update to one per server.

Use of CVS is a good idea for the repository and transport mechanism perhaps with a more 'intelligent' front end comparing what you have installed and what versions are available.  Usually you would not want to checkout from a CVS branch but the static revision tag of a component indicating it's release.  As you say, on a branch and you can not be sure what you're getting.
 
Going down the CVS route, I think each PmWiki plug-in would need to include a common named file e.g. ReadMe at the top level.  The intelligent front end could parse the CVS log on the ReadMe to present to the user the (latest) release revision(s) available for download.
 
I still think a separate repository, let's call it a staging area might simplify things especially if the update mechanism needed nothing more than you already have to run PmWiki (php, web server, browser).  Unless there is a php CVS client class out there that can be reused!
 
Agreed with a Wiki farm as a good practice - centralising the management of more than one site.
 
-Steve.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/pmwiki-users/attachments/20050925/7c74ac46/attachment.html 


More information about the pmwiki-users mailing list