Code Management
 

How do you guys handle testing/deployment for your own servers? I'd like to keep my server code up to date with the svn, and do development on my main pc (using eclipse, since I use ssh to talk to the server).

What I thought I could do is create another svn repository on the server with symlinks to all the files for the eqemu source, that way I could commit changes to my server's svn from eclipse, and still be able to update from the eqemu svn. It'd give me all the advantages of using an svn like being able to compare the different revisions. Unfortunately (and I didn't know this before), svn repos do not contain the files in a traditional directory structure, so that doesn't work.

Anyone tell me how they handle their code modifications?

I have my own SVN repo. When an update comes out from upstream, I use the svn merge command to add the changes to my code.

That's all I do as well. No need to mess around with other programs, svn is all you need.

After asking the same question at graffe's, I figure that's close to what I wanted to do too. Problem is I can't figure out how to make a copy of the eqemu svn on my server.

Just make a copy of it like any other directory. I do it all the time.

I ended up doing a svn import of the code I had checked out (probably could have used the google code svn instead). Deleted the old server code and re-checked it out from my local svn, now I'm having issues performing a merge with the eqemu svn. Probably a syntax thing though.

Alright, this is frustrating me. Maybe one of you who have the svn stuff working can help.

How'd you go about setting it up? Cavedude, did you mean you exported the eqemu svn, then made a copy of it and merged those two? I guess I don't know enough about subversion to understand really what i'm doing.

I've tried checking out the eqemu code and importing it into a fresh svn. This lets me make changes to it from my home computer, but can't figure out how to add in changes from the google code svn later on.

I also tried exporting the eqemu code and merging it with the other code I checked out from before, but that doesn't seem to work (not a working copy error).

Is it as simple as checking out two copies and using svn switch to switch the repository of one to a local one, and using the other to receive updates from the google code svn? Then merging the two when you need to.

Great, there goes the edit button again.

A bit more about svn switch. I tried checking out the google code svn then using svn switch to change repository locations, but it gives me the error '<local repository> is not the same repository as <eqemu repository>. Apparently I can't use --force with svn switch either, which I found referenced online when looking for fixes.

I created my own repo using svn import on a copy of the emu code. Once that was done, I removed that copy of the emu code.

To start working with that code, I checked it out and was then able to make changes, merges, etc. to it and commit those changes to my svn repo at will.

To merge, execute the following in the top of the code checked out from your personal repo:
startrev and endrev define the range of changes to be merged.
url is the url of the repository you are pulling the changes from to merge to your own copy.

After merging the changes, you then have to commit to your repo.

For example, to merge the changes from rev 750 to rev 755 of the emu code into your repo:
There are two caveats of svn merge you should be aware of.

1) If the changes from the merge create a new file, it will give you an error and not perform the merge. To fix this, find the added files and add them to your svn repo before performing the merge. As in:
2) If the changes from the merge conflict with one of your local code changes, you will get a C code from the merge for the affected file. You will have to edit that file to manually merge the changes for the affected areas. The affected areas will be wrapped in tags of the form <<<<<<< and >>>>>> with a ======= separator between the new and the old code. You have to edit that area to clean it up and remove the extra code and the tags and separator. Once you have done that, you need to let svn know you have done so using:
After you have done that for all files with conflicts, you can commit your changes to your repo.

Thanks for the help guys. I think I ended up doing what gaeorn suggested. The problem was trying to do it all server side.

I checked out the official code, copied it over to my working copy, committed that, then made a branch. Now I do my work on one branch and copy over the official code as necessary to another, then merge them.

Sorry to bump this old thread, but I'm just going back and trying this again.

When you do a svn merge, do you always need to specify the revision range you're merging changes from? Basically don't want to have to remember what revision I most recently merged from.

ie. svn merge -rHEAD http://projecteqemu.googlecode.com/s...k/EQEmuServer/

I tried that earlier and I think it did something odd.

I wrote a perl script on my linux box at home, and had planned to set it up as a cron to automatically perform svn checkout if the revision is newer, compile the code, take down the old server, copy the old server directory to a new one, then copy in the new binaries. It worked pretty well for a while. I need to make more changes to it to take into account the changes for compiling with bots, and to make additional changes to my zone/makefile and world/makefile to allow my SoF clients to connect.

basically, my perl script would run the svn command to get the local revision, then get the repository's revision, then die if they matched, or continue if they were different.

Now days, I update once per week (usually Fridays)...

If you're interested, I can post up my perl code for you to take a look at...

Oh yeah, another reason I stopped using it is I decided to change how I name my local server version. Previously, I was using build date to identify them. Then I realized that was a mistake and started using Revision numbers to identify them. So, to keep in line with my new local version tracking, I have to re-write quite a bit of the code in my perl script (and bash scripts that it calls on for that matter), and I haven't found much motivation for doing this lately, because a manual update once per week isn't a big deal to me...