PennMUSH Community
Show
Ignore:
Timestamp:
07/08/07 20:50:12 (1 year ago)
Author:
shawnw
Message:

Merged 1.8.3p4 into trunk

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • 1.8.3/trunk/UPGRADING

    r511 r1032  
    1616Please read them. 
    1717 
    18 The PennMUSH developers actually only support situation A, but 
    19 we'll give some useful tips for B and C here, too. 
     18The PennMUSH developers actually only support situation A, but we'll 
     19give some useful tips for B and C here, too. 
    2020 
    2121DISCLAIMER: It is very wise to always back up your current working 
    …… 
    3131A.1. Upgrading with patch files 
    3232 
    33 This is the easiest way to upgrade your source code if you're  
    34 keeping up with patches as they come out, or if you're upgrading 
    35 patchlevels within a release (e.g., within 1.8.0). 
     33This is the easiest way to upgrade your source code if you're keeping 
     34up with patches as they come out, or if you're upgrading patchlevels 
     35within a release (e.g., within 1.8.0). 
    3636 
    3737To upgrade with patch files, get all the patch files for higher 
    …… 
    4242named things like 1.8.0-patch02 (the patch from 1.8.0p1 to 1.8.0p2) 
    4343or, in some cases, 1.7.6p16-1.8.0p0.patch (the patch from 1.7.6p16 to 
    44 1.8.0p0).  
     441.8.0p0). 
    4545 
    4646Each patch file contains instructions at the top explaining how to 
    47 apply it. FOLLOW THESE! Don't assume they're all the same. 
    48  
    49 After you've applied all the patches and followed all the instructions, 
    50 you should be good to go. In most cases, you can simply @shutdown/reboot 
    51 after the final successful compile. If @shutdown/reboot crashes, 
    52 you'll have to restart again. 
     47apply it. FOLLOW THESE! Don't assume they're all the same. The options 
     48to use with the patch program change, and sometimes further steps are 
     49required. 
     50 
     51After you've applied all the patches and followed all the 
     52instructions, you should be good to go. In most cases, you can simply 
     53@shutdown/reboot after the final successful compile. If 
     54@shutdown/reboot crashes, you'll have to restart again. 
    5355 
    5456A.2. Building a new distribution 
    5557 
    56 When you're upgrading across release and no patchlevel is provided 
    57 to make the upgrade (e.g. from 1.7.4p3 to 1.8.0p0), it's often 
    58 easier to simply build a new distribution following the INSTALL 
    59 instructions, but with your old configuration stuff. 
     58When you're upgrading across release and no patchlevel is provided to 
     59make the upgrade (e.g. from 1.7.4p3 to 1.8.0p0), it's often easier to 
     60simply build a new distribution following the INSTALL instructions, 
     61but with your old configuration stuff. 
    6062 
    6163Move your older version of PennMUSH in a directory called oldpenn/, 
    62 unpack the new one (it will unpack into pennmush/).  
    63  
    64 All of the steps below should be taken before running Configure for the 
    65 new version: 
     64unpack the new one (it will unpack into pennmush/). 
     65 
     66All of the steps below should be taken before running Configure for 
     67the new version: 
    6668 
    6769A.2.a. options.h and game/*.cnf 
    6870 
    69 You can copy the options.h file and game/mush.cnf file from your 
    70 old version to the new version. The 'make update' command (run after 
     71You can copy the options.h file and game/mush.cnf file from your old 
     72version to the new version. The 'make update' command (run after 
    7173Configure) will compare your files with the newly distributed ones and 
    72 tell you about options that have been added or removed. If you have any 
    73 options defined that the new version doesn't recognize, you'll be asked 
    74 if you want to retain them (which is safe). 
     74tell you about options that have been added or removed. If you have 
     75any options defined that the new version doesn't recognize, you'll be 
     76asked if you want to retain them (which is safe). 
    7577 
    7678If your mush.cnf file is called something else, copy it to mush.cnf in 
    77 pennmush/game anyway, since that's the file that gets updated. Then make 
    78 a link to that file called whatever.cnf if you want to use that. 
    79  
    80 If you've modified the restart script, you'll have to decide if 
    81 your modified script is still appropriate, or modify the distributed 
    82 game/restart script again as you like it. The latter is encouraged. 
     79pennmush/game anyway, since that's the file that gets updated. Then 
     80make a link to that file called whatever.cnf if you want to use that. 
     81 
     82If you've modified the restart script, you'll have to decide if your 
     83modified script is still appropriate, or modify a copy of the 
     84distributed game/restart script as you like it. it is highly 
     85recommended that you copy restart to a second file, called something 
     86like restart.local, and modify and use it instead of the stock restart 
     87script to reduce conflicts when patching. 
    8388 
    8489You can also copy your old game/access.cnf, game/sitelock.cnf, and 
    85 game/txt/*.txt files into the appropriate locations. You may wish 
    86 to do the same thing for game/restrict.cnf, but you should compare 
    87 it to the new version, as restrictions that may formerly have been 
    88 compiled into the server may now be specified in restrict.cnf instead. 
     90game/txt/*.txt files into the appropriate locations. You may wish to 
     91do the same thing for game/restrict.cnf, but you should compare it to 
     92the new version, as restrictions that may formerly have been compiled 
     93into the server may now be specified in restrict.cnf instead. 
    8994 
    9095A.2.b. src/*local.c 
    9196 
    9297You should copy local.c, cmdlocal.c, and funlocal.c from oldpenn/src 
    93 to pennmush/src if you want to retain this local code. Of course, 
    94 it may not still work, but it's quite likely that it will. If you 
    95 don't have any such code, you can skip this step. 
     98to pennmush/src if you want to retain this local code. Of course, it 
     99may not still work, but it's quite likely that it will. If you don't 
     100have any such code, you can skip this step. 
    96101 
    97102A.2.c. Databases 
    …… 
    99104This MUSH version should read databases along the main branch of MUSH 
    100105evolution -- TinyMUD, vanilla TinyMUSH up to 2.0, MicroMUSH, and all 
    101 Pern/PennMUSH versions. If you need to convert a TinyMUSH 2.0 database, 
    102 please contact Amberyl, and she'll mail you an extension to 2.0 that 
    103 will dump a 1.50-readable flatfile. You're probably out of luck with 
    104 databases for TinyMUSH 2.2 and later. 
    105  
    106 Be sure that your options.h settings correctly reflect the type 
    107 of password encryption that was used on your database. The default 
    108 has changed to SHS, so if your db used crypt(3) encryption, be 
    109 sure you set the appropriate definition in options.h. 
     106Pern/PennMUSH versions. If you need to convert a TinyMUSH 2.0 
     107database, please contact Amberyl, and she'll mail you an extension to 
     1082.0 that will dump a 1.50-readable flatfile. You're probably out of 
     109luck with databases for TinyMUSH 2.2 and later. 
     110 
     111Be sure that your options.h settings correctly reflect the type of 
     112password encryption that was used on your database. The default has 
     113changed to SHS, so if your db used crypt(3) encryption, be sure you 
     114set the appropriate definition in options.h. 
    110115 
    111116*** If you are upgrading from 1.7.4 (or earlier) to 1.7.7 (or later), 
    …… 
    127132system to one that uses the new flag system (post-1.7.7p5), if you've 
    128133added flags or toggles.  You probably had an #define in hdrs/flags.h 
    129 for your flag's bit value.  This now should be moved to hdrs/oldflags.h; 
    130 you should leave in the table entry in src/flags.c. If you set up a macro 
    131 for testing your flag in hdrs/mushdb.h, you'll need to change it to use 
    132 the has_flag_by_name() function - see the many examples in that file. 
     134for your flag's bit value.  This now should be moved to 
     135hdrs/oldflags.h; you should leave in the table entry in 
     136src/flags.c. If you set up a macro for testing your flag in 
     137hdrs/mushdb.h, you'll need to change it to use the has_flag_by_name() 
     138function - see the many examples in that file. 
    133139 
    134140If this isn't suitable (you're crossing releases or your hacks are too 
    …… 
    139145C. PennMUSH with a lot of hacks 
    140146 
    141 If you've seriously hacked your server source code, you're on your 
    142 own in terms of keeping up with new patchlevels. Some people apply 
     147If you've seriously hacked your server source code, you're on your own 
     148in terms of keeping up with new patchlevels. Some people apply 
    143149patchfiles and fix the rejected hunks. 
    144150 
    …… 
    147153version of pennmush (e.g. 1.7.4p16) to your hacked version of pennmush 
    148154(e.g. 1.7.4p16 with hacks), and then applying those patches to the new 
    149 version of PennMUSH (e.g. 1.8.0p0) to create a hacked version thereof. If 
    150 some patch hunks fail, you'll have to apply them manually. 
     155version of PennMUSH (e.g. 1.8.0p0) to create a hacked version 
     156thereof. If some patch hunks fail, you'll have to apply them manually. 
    151157 
    152158Probably the best approach is to keep all multiple versions of the