From: George C. <ga...@sp...> - 2003-02-17 01:07:38
|
I installed 2.3.0.62 on a clean system, building mod_perl, apache, slash, etc. per the instructions. I wasn't sure how to get Perl to use the CVS version of Bundle::Slash, so I manually installed each of the components listed in the Bundle/slash.pm with CPAN. (Is there a trick to installing the updated Bundle from CVS?) Once slash was running on the new database, with the new templates from CVS, I restored a dumped copy of my production tables into yet another database, and then sourced the /slash_R_2_3_0_62/sql/mysql/upgrades into myql, and it appeared to apply the necessary updates. This left me with two databases: - slashdb New 2.3.0.62 databases, uncustomized - archivedb Original 2.2.6 tables (but with old 2.2.6 version of templates, blocks, etc.) Instead of switching slash over to this upgraded database, I have gradually copied the contents of key tables from my archive slash tables into the new slashdb, by issuing the following command insert into newtable select * from oldtable; I've gradually gotten my site running okay by doing this to the comment_text, discussions, sections, section_topics, story_param, story_topics, story_text, stories, topics, users_count, users_prefs, users_param, users_messages, user_info, user_index, user_hits, users_comments, users_acl and users tables. I assume that I've missed a few tables, but so far things are running okay. Key ones that I figure that I should NOT copy from the old 2.1 system are templates and blocks. Any suggestions on a strategy to move to the CVS version, and how to update to subsequent releases? Rebuild / reinstall every time? Any tricks to make this all a little easier? Thanks, George |
From: shane <sh...@lo...> - 2003-02-17 13:26:24
|
On Sunday 16 February 2003 20:07, George Clark wrote: > I installed 2.3.0.62 on a clean system, building mod_perl, apache, slash, > etc. per the instructions. I wasn't sure how to get Perl to use the > CVS version of Bundle::Slash, so I manually installed each of the > components listed in the Bundle/slash.pm with CPAN. (Is there a trick > to installing the updated Bundle from CVS?) > > Once slash was running on the new database, with the new templates from > CVS, I restored a dumped copy of my production tables into yet another > database, and then sourced the /slash_R_2_3_0_62/sql/mysql/upgrades into > myql, and it appeared to apply the necessary updates. This left me > with two databases: > > - slashdb New 2.3.0.62 databases, uncustomized > - archivedb Original 2.2.6 tables (but with old 2.2.6 version of > templates, blocks, etc.) > > Instead of switching slash over to this upgraded database, I have > gradually copied the contents of key tables from my archive slash tables > into the new slashdb, by issuing the following command > > insert into newtable select * from oldtable; > > I've gradually gotten my site running okay by doing this to the > comment_text, discussions, sections, section_topics, story_param, > story_topics, story_text, stories, topics, users_count, users_prefs, > users_param, users_messages, user_info, user_index, user_hits, > users_comments, users_acl and users tables. OMG did you do this the totally hard way. > I assume that I've missed a few tables, but so far things are running > okay. Key ones that I figure that I should NOT copy from the old 2.1 > system are templates and blocks. > > Any suggestions on a strategy to move to the CVS version, and how to > update to subsequent releases? Rebuild / reinstall every time? Any > tricks to make this all a little easier? The general idea, to update 1. is you take the 'upgrades' file, edit out of if what you don't need, and then apply it to the db. 2. check your templates, or reload them. you're pick. but you need to find it if any changes were made 3. make install && apachectl restart && slashd restart I just went through the entire upgrade process, 2 or 3 weeks ago, for all my sites. They were running fry, and some were running fry with more up-to-date messaging code. I went about upgrading the sites a bit differently from what you did. I setup a text file, which I could pipe to into a term window, for each site. And I did the entire upgrade sequence, for each site, over and over, until all errors were fixed, and it seemed to upgrade a-ok. Each site has it's own theme. Each site has it's own upgrade.sql file (because each site doesn't have the same plugins installed). And each site eventually had it's own post and preupgrade.sql files. (this was really to satisfy my own needs, but to each his own). Here's a link to one of the scripts: <URL: http://lottadot.com/shane/upgradescript.txt > Here's a link to the post-upgrade file: <URL: http://lottadot.com/shane/postupgrade.sql.txt > The month before I actually did the upgrade on the production site, I messed with cosmetics. I took the CVS tree that each theme for each site is in, and branched it. Then started changing the graphcis, colors, sql, etc. The tabbed menu system, while kickass, has a *lot* of graphic files in it. That took a long time to figure out, and create graphics for, for each site. But that meant that the themes were set. When I did the final make install on the production box, piped in the portions of each site's upgrade files, started slashd and apache my sites were working nearly perfectly. Since I did this, I've found a few different things: 1. There is login in the theme installer to handle sub directories under htdocs. So I need to modify my themes accordingly. I'll get to it someday. 2. The sql fix to fix the admin menus. I incorporated it into my postupgrade.sql file. 3. I had to remember to reset the mySQL account's password so it existed. For the upgrade process I removed it so that I could just pipe the text into the xterm. yeah, it's very ineligent, but after doing a number of site upgrades, I was totally sick of typing the same damn commands over, and over, over. And I wanted to know that my sites worked and there weren't any unexplainable errors during the install process. Anyway, I know this was kinda long. I hope it helps you. Shane |