[CS-Project-svn_notify] SF.net SVN: cs-project: [856] trunk/1.2

[<cra...@us...>]

Revision: 856
          http://cs-project.svn.sourceforge.net/cs-project/?rev=856&view=rev
Author:   crazedsanity
Date:     2008-03-26 21:43:00 -0700 (Wed, 26 Mar 2008)

Log Message:
-----------
More thoughts on the upgrade, plus "rw" directory for reading & writing stuff.

Modified Paths:
--------------
    trunk/1.2/upgrade/upgradeTo1.2.0-ALPHA4.php

Added Paths:
-----------
    trunk/1.2/rw/


Property changes on: trunk/1.2/rw
___________________________________________________________________
Name: svn:ignore
   + *.xml


Modified: trunk/1.2/upgrade/upgradeTo1.2.0-ALPHA4.php
===================================================================
--- trunk/1.2/upgrade/upgradeTo1.2.0-ALPHA4.php	2008-03-27 04:34:34 UTC (rev 855)
+++ trunk/1.2/upgrade/upgradeTo1.2.0-ALPHA4.php	2008-03-27 04:43:00 UTC (rev 856)
@@ -41,57 +41,30 @@
 		
 		$configFileContents = $fs->read(CONFIG_FILE_LOCATION);
 		
+		//TODO: test that /rw is readable & writable
+		//TODO: write to new config file location
+		//TODO: delete old config file
+		
 		/* 
-		 * PROBLEM: the config file MUST be readable in the specified location...
-		 * once it is moved, the site config needs to be updated to point at the 
-		 * new location... we could throw an error here, explaining that the 
-		 * file needs to be moved manually, but if the user upgrades to the NEXT 
-		 * version, the system would believe that there's a problem because the 
-		 * config file would be MISSING (they'd have to go through setup all over
-		 * again, even though they have an existing WORKING db)...
+		 * PROBLEMS WITH MOVING THE CONFIG FILE:
+		 * 1.) upgrades currently won't survive (through multiple version updates) 
+		 * if the config location changes, since it is statically set.
 		 * 
-		 * STEPS THAT NEED TO OCCUR:::
-		 * 1.) move the config file to /rw/config.xml from /lib/config.xml
-		 * 2.) ensure the site_config points to the CURRENT config file
-		 * 		OPTIONS:
-		 * 			a.) set "trigger" to look for old config when rw/config.xml
-		 * 				is missing & do the proper change (must be set prior 
-		 * 				to the upgrade/setup system checks)
-		 * 					++ ALPHA3 -> ALPHA4 would work
-		 * 					-- potentially breaks future upgrades
-		 * 					-- bypasses upgrade system
-		 * 			b.) scriptify direct modification of the site_config.php file
-		 * 				so it points to the new location during this upgrade
-		 * 					++ ALPHA3 -> ALPHA4 would work
-		 * 					++ doesn't bypass upgrade system
-		 * 			c.) drop all auto-upgrades prior to this one (ALPHA4), with 
-		 * 				moving the config file being the FIRST step, then run 
-		 * 				ALL other changes; it's an ALPHA, so things are 
-		 * 				expected to possibly be hairy.
-		 * 					-- developers running pre-ALPHA4 will have problems
-		 * 					++ ALPHA3 -> ALPHA4 would work
-		 * 					++ doesn't bypass upgrade system
-		 * 3.) systems upgrading from 1.1 must be able to do so automatically.
+		 * 2.) upgrades from 1.1 MUST be able to work automatically.
 		 * 
-		 * PROBLEMS:
-		 * 1.) setup MUST know where current config file is: if it is pointing 
-		 * to the NEW location and it exists in the OLD, setup will run; if it 
-		 * is pointing to the OLD location but it's in the NEW, setup will run.
-		 * 		a.) if 1.2 (post-ALPHA4) always expects config to be in the new
-		 * 			location, those caught in the mix can just manually move it
-		 * 			to the new location
-		 * 		b.) no reason to believe it would EVER point to the old location 
-		 * 			when there's one in the new location.
+		 * 3.) upgrades MUST BE SURVIVABLE through multiple version changes (see #1) 
 		 * 
+		 * SOLUTION:
 		 * 
+		 * TODO: add "trigger" to check for old config file; if old config exists, bypass setup & go to upgrade.
 		 * TODO: remove support for pre-alpha4 installs
 		 * TODO: consolidate pre-alpha4 changes into alpha4 upgrade
 		 * TODO: warn existing developers of changes and how to manually upgrade (update to r{x}, let setup run, update db + VERSION file)
+		 * 
+		 * NOTE: while it might cause headaches for one or two developers, this 
+		 * minimizes pain for users upgrading from previous versions.  Yay.
 		 */
 		
-		$this->gfObj->debug_print($this->gfObj->cleanString($updateXml->create_xml_string(), 'htmlentity_plus_brackets'));
-		$fs->openFile(CONFIG_FILE_LOCATION);
-		$fs->write($updateXml->create_xml_string());
 	}//end update_config_file()
 	//=========================================================================
 }


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.