<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wikidot="http://www.wikidot.com/rss-namespace">

	<channel>
		<title>Staging and Production Servers</title>
		<link>http://dev.wikidot.org/forum/t-43643/staging-and-production-servers</link>
		<description>Posts in the discussion thread &quot;Staging and Production Servers&quot; - Testing before overwriting production wikidot server.</description>
				<copyright></copyright>
		<lastBuildDate></lastBuildDate>
		
					<item>
				<guid>http://dev.wikidot.org/forum/t-43643#post-115207</guid>
				<title>Re: Staging and Production Servers</title>
				<link>http://dev.wikidot.org/forum/t-43643/staging-and-production-servers#post-115207</link>
				<description></description>
				<pubDate>Thu, 28 Feb 2008 11:31:16 +0000</pubDate>
				<wikidot:authorName>michal frackowiak</wikidot:authorName>				<wikidot:authorUserId>1</wikidot:authorUserId>				<content:encoded>
					<![CDATA[
						 <p>Hi,</p> <p>yes, we want to implement such functionality in WD2 and this could be done in at least 2 ways (btw: now it is a good time to discuss which is better):</p> <p>1. Draft/unpublished mode</p> <p>One could edit pages and save without publishing. This would mean that a page (or whole wiki) could have 2 versions: current and published. This would add extra structures to the site and myself I am not a big fan of this solution because I find it lacking flexibility.</p> <p>2. Cloning &amp; merging back</p> <p>To keep a page/category/wiki in a consistent state one does not edit live pages, but instead "clones" a page/category/wiki and makes changes to the working copy. When changes are done (and reviewed), they can be merged back to the original source. Since the <em>clone</em> operation links the original and cloned content, merging back should be easy and straightforward.</p> <p>The solution 2 is inspired by how distributed version control systems work (e.g. <a href="http://www.selenic.com/mercurial/">Mercurial</a> or <a href="http://bazaar-vcs.org/">Baazar</a>). If we can implement a nice merge tool, several people could easily work on the same document (different copies) and push the changes back to the original container.</p> <p>IMHO it gives nice flexibility and could be adapted in various workflows. The clone-edit-review-publish would nicely work with the permission system.</p> <p>We are not really planning this for the "alpha release" of WD2 (in the next few months) but this is a must eventually. Michal Bartoszewski (<span class="printuser avatarhover"><a href="http://www.wikidot.com/user:info/e1n" ><img class="small" src="http://www.wikidot.com/common--images/avatars/19/19928/a16.png" alt="e1n" /></a><a href="http://www.wikidot.com/user:info/e1n" >e1n</a></span>) is working on adapting a 3-way XML merge tool (I think <a href="http://tdm.berlios.de/3dm/doc/index.html">this one</a>) to this scenario but any help from XML experts would be highly appreciated.</p> <p>best,<br /> Michal</p> 
				 	]]>
				</content:encoded>							</item>
					<item>
				<guid>http://dev.wikidot.org/forum/t-43643#post-114450</guid>
				<title>Staging and Production Servers</title>
				<link>http://dev.wikidot.org/forum/t-43643/staging-and-production-servers#post-114450</link>
				<description></description>
				<pubDate>Wed, 27 Feb 2008 08:09:14 +0000</pubDate>
				<wikidot:authorName>Jerry Schneider</wikidot:authorName>				<wikidot:authorUserId>59278</wikidot:authorUserId>				<content:encoded>
					<![CDATA[
						 <p>Currently on Wikidot1, I have to edit the "live" pages, and if there are lots of interacting changes, sometimes it leaves the site in an inconsistent state for visitors. I'm used to having a staging server that holds the pre-production version, and when things on the staging server are working well, I throw the switch (well, actually someone pauses the server, copies the file paths from the staging server to the production server, and restarts the production server.)</p> <p>Any thoughts on doing a similar operation on Wikidot, either 1 or 2? One site I know of uses port 8080 for staging and 80 for production, while another has two URLs, one for each type.</p> <p>If there were a quick "restore from zip" mode, I could zip the staging WD server and restore the zip to the main WD server, after first clearing it (deleting it?). Something that doesn't involve requests to the WD admin so I can roll forward/roll back as needed.</p> <p>Thoughts, suggestions. WD2 solution already in the works?</p> <p>TIA</p> 
				 	]]>
				</content:encoded>							</item>
				</channel>
</rss>