Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
 parse description bug
Yesterday, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
Bug in will_fall( )
Oct 23, 2017, 1:35 am
By GatewaySysop
Bug in do_zap( ), do_brandish( )
Oct 18, 2017, 1:52 pm
By GatewaySysop
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Memwatch
Author: Johan Lindh
Submitted by: Vladaar
Users Online
CommonCrawl, Yahoo!

Members: 0
Guests: 9
Stats
Files
Topics
Posts
Members
Newest Member
477
3,706
19,240
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » AFKMud Support & Development » Upgrading a codebase
Forum Rules | Mark all | Recent Posts

Upgrading a codebase
< Newer Topic :: Older Topic > how does one upgrade a codebase

Pages:<< prev 1 next >>
Post is unread #1 May 30, 2003, 10:14 pm
Go to the top of the page
Go to the bottom of the page

Amalric

GroupMembers
Posts48
JoinedMay 15, 2003

I have noticed that upgrades to the codebase have been coming out fairly regularly. What is the best way to upgrade a codebase if you already have a prior version compiled and working?
While I am not this far yet this would be good info to know for the near future.
       
Post is unread #2 May 31, 2003, 12:01 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Best way: Make a backup and test the patches that would bring you up to the latest version on your code at that point. If they fail, then at least if you manage to botch patching in the rest, you'll have a backup to fall back on
       
Post is unread #3 Jun 3, 2003, 5:30 am
Go to the top of the page
Go to the bottom of the page

Xorith
The Null Value
GroupAFKMud Team
Posts254
JoinedFeb 23, 2003

Just to clarify what Samson said... *G*

you can always do this:
(from the root directory of your mud, ie: ~/afkmud/)
tar -vczf source_backup.tgz ./src/*.c ./src/*.h ./src/Makefile ./src/startup

This will make a tarball of your source

Then, cp the patch file (ie: cp 152patch ~/afkmud/src/ )

Then type: patch < *patch file* (ie: patch < 152patch )

If you haven't done much modding, it shouldn't be a problem. If you have, then you might have 'failed hunks'. These are stored in files like this: (file).rej.. If hunks failed in mud.h, it'd be saved as: mud.h.rej

Open up a rej file and you'll see the way it was suppose to look, and the way it should look now. You can then use a simple search function found in must text editors to make the changes manually.

If you don't know wether or not hunks failed, since it does scroll fast... you can always do an 'ls *.rej' in your source directory.

To clean up, type: rm *.rej *.orig 152patch (note: sub 152patch for whatever the patchfile was). You may even wish to archive these files for later use and/or debugging...

tar -vczf 152patch_arch.tgz *.rej *.orig 152patch

Hope this helps
       
Post is unread #4 Jun 3, 2003, 5:46 am
Go to the top of the page
Go to the bottom of the page

Amalric

GroupMembers
Posts48
JoinedMay 15, 2003

Thank you to both Samson and Xorith! That is just what I was looking for. One question for Xorith... when you say "If you haven't done much modding..." Do you mean mods to the codebase itself and mobprogs or general building and populating? Sory but I'm still new to some of the admin type terms.
       
Post is unread #5 Jun 3, 2003, 6:07 am
Go to the top of the page
Go to the bottom of the page

Xorith
The Null Value
GroupAFKMud Team
Posts254
JoinedFeb 23, 2003

When I say mod, I mean hard-coded changes to the server. Meaning you popped open a .c or .h file and made changes.

Anything as far as online content is called building usually, or OLC.

It's also a good thing to comment changes you *do* make. For example, I group all my code changes into a mudlib called 'NeoCode', currently building version 0.06a If I make a modification, let it be bugfix or addition, I always have something like this:
/* NeoCode 0.06a -- BugFix by Xorith */

I change the version depending on what my working version is and I usually describe a bit more if possible or worth while.

This saved me once when a patch went very wrong and I nearly lost my source. I just did: grep 'NeoCode' *.c > neocode_c, and grep 'NeoCode' *.h > neocode_h. This allowed me to isolate the changes I made and quickly paste them into a freshly downloaded copy of AFKMud

I also make a strong effort of putting any *major* updates into a seperate file, namely neocode.c or neocode.h. This makes patching easier since the files are still *somewhat* the same. If you do this, you should always pay attention to what's added with a patch. If you copied a function from the main source and modified it for whatever reason, but there was a bug fixed... You might've put that new function into your mudlib.c file. The bug might still be there since you just modded the function, thus the bug never gets patched.

Hope this gives some ideas! It's nearly impossible to truely seperate mods from base, but the more you can do it the easier patching is.
       
Pages:<< prev 1 next >>