05 Dec, 2008, David Haley wrote in the 62nd comment:
I haven't done it very often so I don't know the commands off the top of my head for a given version control system. The gist of it is that you branch the source at one revision, and then use the merge command starting from another revision. Or, you get the repository at version X+1, where X+1 is the one you want to skip; then you ask the VCS for the diff from X to X+1, you apply it in reverse, and then you retrieve the rest of the revisions.
This isn't something you'd do terribly often; much more likely is that you'd realize that revision X+1 caused the problem, and then you'd look at X to X+1, and reverse those changes "by hand" (meaning using a diff tool of some sort) in whatever revision X+y you happen to be in presently.
This isn't something you'd do terribly often; much more likely is that you'd realize that revision X+1 caused the problem, and then you'd look at X to X+1, and reverse those changes "by hand" (meaning using a diff tool of some sort) in whatever revision X+y you happen to be in presently.
05 Dec, 2008, Tyche wrote in the 63rd comment:
Well that deficiency is with the copyover code (also illustrated by your crash). I don't know which version of copyover you're using but the following patch to the vanilla Erwin's copyover ought to be more forgiving than aborting the mud.
void do_copyover (CHAR_DATA *ch, char * argument)
{
FILE *fp;
DESCRIPTOR_DATA *d, *d_next;
char buf [100], buf2[100];
/* patch starts here */
struct stat info;
if (!stat(EXE_FILE, &info))
{
send_to_char ("Can't copyover. Executable doesn't exist.\r\n",ch);
logf ("Could not find mud executable: %s", EXE_FILE);
return;
}
/* patch ends here */
fp = fopen (COPYOVER_FILE, "w");
..blah blah..
}
05 Dec, 2008, Igabod wrote in the 64th comment:
Tyche said:
Well that deficiency is with the copyover code (also illustrated by your crash). I don't know which version of copyover you're using but the following patch to the vanilla Erwin's copyover ought to be more forgiving than aborting the mud.
void do_copyover (CHAR_DATA *ch, char * argument)
{
FILE *fp;
DESCRIPTOR_DATA *d, *d_next;
char buf [100], buf2[100];
/* patch starts here */
struct stat info;
if (!stat(EXE_FILE, &info))
{
send_to_char ("Can't copyover. Executable doesn't exist.\r\n",ch);
logf ("Could not find mud executable: %s", EXE_FILE);
return;
}
/* patch ends here */
fp = fopen (COPYOVER_FILE, "w");
..blah blah..
}
i did this and got a couple errors i'm unsure of, here's the entire results of that.
–> Compiling file: act_wiz.c <–
act_wiz.c: In function `do_copyover':
act_wiz.c:6644: error: storage size of 'info' isn't known
act_wiz.c:6646: warning: implicit declaration of function `stat'
act_wiz.c:6649: warning: implicit declaration of function `logf'
act_wiz.c:6649: error: incompatible type for argument 1 of `logf'
act_wiz.c:6649: error: too many arguments to function `logf'
act_wiz.c:6644: warning: unused variable `info'
make: *** [obj/act_wiz.o] Error 1
going down the list, i've got no clue what the storage size of 'info' isn't known error means. i know what the implicit declaration warnings are and have fixed the implicit declaration of logf by changing every instance of it in the code to logprintf. No clue what "incompatible type for argument 1 of logf" means and the too many arguments error i know, as well as the unused variable 'info' warning.
I fixed a couple of these warnings by changing the logf in the code you gave me to logprintf but i get these warnings now.
act_wiz.c: In function `do_copyover':
act_wiz.c:6644: error: storage size of 'info' isn't known
act_wiz.c:6646: warning: implicit declaration of function `stat'
act_wiz.c:6649: warning: passing arg 1 of `logprintf' from incompatible pointer
type
act_wiz.c:6644: warning: unused variable `info'
make: *** [obj/act_wiz.o] Error 1
any insight into fixing these would be appreciated.
[edit to add] i fixed the warning passing arg 1 of logprintf by adding NULL, before the "Could not find mud executable" part. It appears that the &info portion isn't being used. So the question is should I just delete that? As for the implicit declaration of stat, would i need to change that to something else like status or what?
05 Dec, 2008, Lobotomy wrote in the 65th comment:
The problem is that you don't have the header file that contains the information for the stat structure and function. You'll need to add "#include <sys/stat.h>" to your header file include section.
05 Dec, 2008, Igabod wrote in the 66th comment:
ah that fixed it right up, thank you lobotomy.
05 Dec, 2008, Igabod wrote in the 67th comment:
Tyche gave me the copyover install portion to add to my makefile and I've followed the instructions and it works. I was wondering however why I would want old_merc.exe to still be in my area directory after merc.exe is copied there?
Shouldn't it rm -f old_merc.exe after merc.exe is placed there?
Also, you mentioned something about the copyover code pointing to ../area/merc.exe but it doesn't, it points to ../src/merc.exe should i change it to point to the former?
[edited to add the last question and to format it so the questions are easier to differentiate from eachother.]
Shouldn't it rm -f old_merc.exe after merc.exe is placed there?
Also, you mentioned something about the copyover code pointing to ../area/merc.exe but it doesn't, it points to ../src/merc.exe should i change it to point to the former?
[edited to add the last question and to format it so the questions are easier to differentiate from eachother.]
06 Dec, 2008, Igabod wrote in the 68th comment:
I should know better than to say something works just because it compiled fine. I did the change to do_copyover that Tyche gave me and for some reason it's saying Can't copyover. Executable doesn't exist. My thoughts are that this is because the location of EXE_FILE isn't defined till after that in the function. Sadly I'm unsure as to where this piece of code should be moved. Here's a copy of my do_copyover.
I've got the code Tyche gave me commented out for the moment, the rest of those comments were already there.
void do_copyover (CHAR_DATA *ch, char * argument)
{
FILE *fp;
DESCRIPTOR_DATA *d, *d_next;
char buf [100], buf2[100];
/*
struct stat info;
if (!stat(EXE_FILE, &info))
{
send_to_char ("Can't copyover. Executable doesn't exist.\r\n",ch);
logprintf (NULL,"Could not find mud executable: %s", EXE_FILE);
return;
}
*/
fp = fopen (COPYOVER_FILE, "w");
if (!fp)
{
send_to_char ("Copyover file not writeable, aborted.\n\r",ch);
logprintf (NULL,"Could not write to copyover file: %s", COPYOVER_FILE);
perror ("do_copyover:fopen");
return;
}
/* Consider changing all saved areas here, if you use OLC */
do_call( ch,"all");
do_forceauto(ch,"save");
if (IS_SET(ch->in_room->room_flags, ROOM_TOTAL_DARKNESS))
{
REMOVE_BIT(ch->in_room->room_flags, ROOM_TOTAL_DARKNESS);
}
//LALA
if ( IS_SET(ch->flag2, AFF2_INARENA) || IS_SET(ch->flag2,AFF2_CHALLENGED)
|| IS_SET(ch->flag2, AFF2_CHALLENGER))
{
REMOVE_BIT(ch->flag2, AFF2_CHALLENGED);
REMOVE_BIT(ch->flag2, AFF2_CHALLENGER);
REMOVE_BIT(ch->flag2, AFF2_INARENA );
undo_arena(ch);
arena = FIGHT_CLEAR;
}
do_asave (NULL, "");
sprintf (buf, "\n\r *** COPYOVER by %s - please remain seated!\n\r", ch->name);
/* For each playing descriptor, save its state */
for (d = descriptor_list; d ; d = d_next)
{
CHAR_DATA * och = CH (d);
d_next = d->next; /* We delete from the list , so need to save this */
if (!d->character || d->connected > CON_PLAYING) /* drop those logging on */
{
write_to_descriptor (d->descriptor, "\n\rSorry, we are rebooting. Come back in a few minutes.\n\r", 0);
close_socket (d); /* throw'em out */
}
else
{
fprintf (fp, "%d %s %s\n", d->descriptor, och->name, d->host);
save_char_obj (och);
write_to_descriptor (d->descriptor, buf, 0);
}
}
fprintf (fp, "-1\n");
fclose (fp);
/* Close reserve and other always-open files and release other resources */
fclose (fpReserve);
/* exec - descriptors are inherited */
sprintf (buf, "%d", port);
sprintf (buf2, "%d", control);
execl (EXE_FILE, "../src/merc.exe", buf, "copyover", buf2, (char *) NULL);
/* Failed - sucessful exec will not return */
perror ("do_copyover: execl");
send_to_char ("Copyover FAILED!\n\r",ch);
/* Here you might want to reopen fpReserve */
}
I've got the code Tyche gave me commented out for the moment, the rest of those comments were already there.
06 Dec, 2008, Littlehorn wrote in the 69th comment:
Looks like it's in the function to me and the EXE_FILE is where your merc.exe path is defined. I don't see it defined in this snippet of code, so where is it? It should look like this:
Assuming if it compiled fine then it is defined and maybe your problem lies there in the path. Also is this on Cygwin?
#define EXE_FILE "../src/merc.exe"
Assuming if it compiled fine then it is defined and maybe your problem lies there in the path. Also is this on Cygwin?
06 Dec, 2008, Igabod wrote in the 70th comment:
it's defined in merc.h and yes and no, it's doing this both on cygwin and on my shell account. And the path of the define is the same as the path of execl in the code i posted above.
06 Dec, 2008, Tyche wrote in the 71st comment:
Igabod said:
Shouldn't it rm -f old_merc.exe after merc.exe is placed there?
I assume you mean the install target in the makefile. No, you cannot remove it if you wanted to until after copyover. My response to Scandum was intended to illustrate the access issues. The make install target does removes an existing old_merc.exe before copying the merc.exe, so you don't have to worry about it.
I would add that while you could run 'make install' twice in a row without doing a copyover or restarting the mud, you would get error messages from the first two (rm and mv) commands. Those error messages could be safely ignored.
Igabod said:
Also, you mentioned something about the copyover code pointing to ../area/merc.exe but it doesn't, it points to ../src/merc.exe should i change it to point to the former?
Tyche ..earlier said:
I'm going to assume that the live executable (the one the startup script and the hardcoded copyover point to) reside in the area directory, and that the build target executable resides in the src directory. They could reside elsewhere, but the point of the exercise is the build process doesn't target the live executable.
06 Dec, 2008, Littlehorn wrote in the 72nd comment:
Nevermind Tyche replied. <removed>
06 Dec, 2008, Tyche wrote in the 73rd comment:
Igabod said:
I should know better than to say something works just because it compiled fine. I did the change to do_copyover that Tyche gave me and for some reason it's saying Can't copyover. Executable doesn't exist.
That means it's working. That is to say that whatever EXE_FILE is, it does not exist.
06 Dec, 2008, Littlehorn wrote in the 74th comment:
Tyche said:
That means it's working. That is to say that whatever EXE_FILE is, it does not exist.
Igabod said:
I should know better than to say something works just because it compiled fine. I did the change to do_copyover that Tyche gave me and for some reason it's saying Can't copyover. Executable doesn't exist.
That means it's working. That is to say that whatever EXE_FILE is, it does not exist.
Working? Sure, the catch is working. Does that mean it's doing what it should? No… Define why it's there for him if EXE_FILE defines the location… :smirk:
06 Dec, 2008, Igabod wrote in the 75th comment:
Tyche said:
That means it's working. That is to say that whatever EXE_FILE is, it does not exist.
Igabod said:
I should know better than to say something works just because it compiled fine. I did the change to do_copyover that Tyche gave me and for some reason it's saying Can't copyover. Executable doesn't exist.
That means it's working. That is to say that whatever EXE_FILE is, it does not exist.
no EXE_FILE definately exists, it's on line 3911 of merc.h and it looks like this:
#define EXE_FILE "../src/merc.exe"
06 Dec, 2008, Littlehorn wrote in the 76th comment:
Igabod said:
no EXE_FILE definately exists, it's on line 3911 of merc.h and it looks like this:
Tyche said:
That means it's working. That is to say that whatever EXE_FILE is, it does not exist.
Igabod said:
I should know better than to say something works just because it compiled fine. I did the change to do_copyover that Tyche gave me and for some reason it's saying Can't copyover. Executable doesn't exist.
That means it's working. That is to say that whatever EXE_FILE is, it does not exist.
no EXE_FILE definately exists, it's on line 3911 of merc.h and it looks like this:
#define EXE_FILE "../src/merc.exe"
The catch is not needed for the function to work. Did you try copying over with it commented out like you had in your code quote? I would try that and step backwards to see if the path is defined incorrectly or the catch giving you the error is maybe not working correctly or the way you need it to. On that note, the path might look correct to you but for some reason is not correct to your code. You can always try declaring the full path of the merc.exe
06 Dec, 2008, Tyche wrote in the 77th comment:
Littlehorn said:
Working? Sure, the catch is working. Does that mean it's doing what it should? No… Define why it's there for him if EXE_FILE defines the location… :smirk:
But Sharmair already explained that EXE_FILE macro defines it, and that the 2nd parameter of execl is not used to locate it. I think Cygwin might use arg0 to set the bash window title or the process name, so you could set the 2nd parameter to something really cool like "MonkeyButts". It looks like it might be a relative path from the working directory, which is probably determined in the startup script (which of course needs to be the same as EXE_FILE). So maybe it exists, maybe it doesn't, maybe it exists but not in a relative way.
06 Dec, 2008, Igabod wrote in the 78th comment:
yeah it works completely fine (and by works, I mean I actually tested it this time) with tyche's code commented out.
06 Dec, 2008, Tyche wrote in the 79th comment:
Igabod said:
yeah it works completely fine (and by works, I mean I actually tested it this time) with tyche's code commented out.
Oh believe me it works when it's commented in too.
06 Dec, 2008, Igabod wrote in the 80th comment:
If it works then I should be able to copyover. I have everything I need in the right place don't I? What am I missing here?
[edit to add] I didn't see your other post before the last one. You are one cryptic guy you know that Tyche? One minute you're extremely helpful and the next I can't understand you at all…
[edit to add] I didn't see your other post before the last one. You are one cryptic guy you know that Tyche? One minute you're extremely helpful and the next I can't understand you at all…
I hadn't thought of it the way you explained it david, I do see what you mean and will do my best to improve my old habits on here. I can't make any promises because I've been typing the same way since I was 12 years old, but I will try.
Regarding the answer about git vs tar … hehe git tar, guitar,… sorry, got diverted there… you mentioned being able to skip a change while still leaving changes that were made after that in. How does this work? While I understand the concept, I'm unable to picture the actual practice. It sounds like quite the nifty feature.
There are likely going to be follow-ups on why during the build process rm -f merc.exe or gcc -o merc.exe are failing because of access errors. Assuming at some point the OP actually sees the failure messages, whether they be suppressed or in the wrong color. Factoring in the use of Erwin's copyover code and Cygwin compounds the already lame practice of making the live executable the target or removing it prior to the build process. Now the general reason why removal of the target is bad is that the mud might crash and restart, be manually rebooted, or "copyovered/hotbooted" anytime prior to creating a working target executable. It's a problem independent of operating system and with players waiting for the game to return the situation is less than ideal. On windows, and this includes cygwin (as cygwin processes are windows processes), executables and dlls are treated as memory mapped files and are locked while the process is alive. There's a trick to get around access issues by installing a new executable by renaming the running one, before copying a new one and hotbooting the mud.
I'm going to assume that the live executable (the one the startup script and the hardcoded copyover point to) reside in the area directory, and that the build target executable resides in the src directory. They could reside elsewhere, but the point of the exercise is the build process doesn't target the live executable.
Thank you for the info Tyche I'll look into this later tonight. However if I change the name of the executable, then if somebody were to do a copyover before the new one is created wouldn't the mud crash? Granted it's not likely to happen with that split second precision but stranger things do happen.