Code Management

[pfyon]

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?

[gaeorn]

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.

[cavedude]

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

[pfyon]

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.

[cavedude]

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

[pfyon]

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.

[pfyon]

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.

[prickle]

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...

[prickle]

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...