Updating Core...

[Sealiah]

Alright so, before you get upset and tell me to look in the Installation, upgrades forum, let me explain my problem.

I know how to do an update(thanks to the stickied thread in the aforementioned forum) but my problem is that I can't.

When I compiled my server, I compiled it on my local machine and then uploaded it to another computer for use.

On that other computer, when I right click on my server folder and do "Git GUI Here" it brings up the first git box with the repo options (Create New Repo, Clone Existing, etc...)

So, how can I update the server without having to compile a new core?

Thank you ahead of time

-------------------------

Another issue I could use some help with...

How can I switch/combine db's?

I'm currently using UDB. I would like to combine it with YTDB but have no clue how to go about doing this.

Thanks again ahead of time

[FragFrog]

So, how can I update the server without having to compile a new core?

You can't. The only thing updated is the source. To run source you have to compile it. Ergo, to update your server you must first update your source, then compile it and then copy the new core to your server.

Of course, alternatively you can use binary server packs, there's a few repo's around for those. Use at your own risk though.

[Sealiah]

You can't. The only thing updated is the source. To run source you have to compile it. Ergo, to update your server you must first update your source, then compile it and then copy the new core to your server.

Of course, alternatively you can use binary server packs, there's a few repo's around for those. Use at your own risk though.

But I have made custom core modifications to my server core

[FragFrog]

In that case you can either create your own local branch and merge it with the official repositories, or create patches and reapply those after updating. That's how I do it, I generally spend a few hours after each update applying patches, compiling, testing and adjusting patches where necessary. Most tend to go allright, but with over a dozen patches there's generally one or two that break with any major update.

Once we get a good working version on test it's comitted to an SVN repository with binaries, so on the live server we can simply do an update to get the latest version. We have used FTP in the past, but it's generally not a bad idea to be able to rollback the core to a previous state without having to recompile and all that.

It's also the reason we don't update more often than once a month or so, preparing and testing an update simply takes too much time to do it every week

[Sealiah]

Ah, I see.

What a pain lol

Alright, sorry for being such a noob, this is my first experience with MaNGOS and everything is very new to me.

How would I go about creating a patch? lol...

I've looked over this -> http://getmangos.eu/wiki/Patch_Submission_Guidelines

But, that's not exactly what I want. Isn't there a way to create a patch without having to create a new branch and all that jazz?

Apologies and thank you again

[FragFrog]

To be honest, I am not sure what I do is the best way, but patches tend to be easier for me then making a new branch and all that (of course, I primarily use SVN, experienced GiT users will probably find branching and merging easier).

To make a patch (I always use the command line for this, and this assumes you already have a local copy checked out):

First, after modifying the core I check the status:

Z:\\Mangos\\TBC\\mangos-10160-sd2-1737>git status
# On branch 243
# Your branch is ahead of 'origin/mangos-0.12' by 1 commit.
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   src/shared/ServiceWin32.cpp
#       modified:   src/shared/ServiceWin32.h
#
no changes added to commit (use "git add" and/or "git commit -a")

This is from my current development repository. As you can see, there are a few changed files. I add those to the next commit:

Z:\\Mangos\\TBC\\mangos-10160-sd2-1737>git add src/shared/ServiceWin32.cpp
Z:\\Mangos\\TBC\\mangos-10160-sd2-1737>git add src/shared/ServiceWin32.h

Now I can commit the files I just added. The -m modifier allows me to enter a message for this commit, which will be used as name for the patch file.

Z:\\Mangos\\TBC\\mangos-10160-sd2-1737>git commit -m "Allow custom service name"
[243]: created 14ad865: "Allow custom service name"
2 files changed, 28 insertions(+), 0 deletions(-)

Allright, files are added, committed, now all we need to do is make a patch file out of them:

Z:\\Mangos\\TBC\\mangos-10160-sd2-1737>git format-patch -1
0001-Allow-custom-service-name.patch

Et voila, I now have a file '0001-Allow-custom-service-name.patch' with the changes required. To apply it on a clean checkout I can just hit 'git apply [filename]' and it will apply this patch.

As said, this is what works for me, but I do believe GiT is more commonly used in a branching / merging fashion where you create a (local) repository with your own changes and simply merge updates from the official repositories into it. This is probably easier as well, although it might be a bit tricky when you want to exclude a patch at some point (for example, when something gets fixed that you used to have a hacky patch for, you'll not want your hack but the official fix). I am sure one of the more experienced GiT users can explain that in more detail

[Sealiah]

Alright, compiling a new core() and then I'll test this out and let you know

[Toinan67]

Interesting thread.

I was quite sure there was a better way than spending hours fixing, adjusting and testing the same patches every time you want to update ("what a pain" as you said )

Using the git local branch method, I believe it will be almost the same for adjusting our modifications, right?

So the right order would be :

Creating the local branch :

git branch my_local_branch

Go to this branch :

git checkout my_local_branch

And once you have done all your modifications, go to the branch master, apply all your work to it, and then pull from the official mangos sources :

git checkout master
git merge my_local_branch
git pull

At this point, we may have a few errors I suppose.

Am I right with all that?

[Schmoozerd]

I wouldn't merge the development branch into master, but rather keep master clean, and use a main custom branch for all the local changes.

in this way, you can update your master always with "git pull" - without conflicts,

and you have your custom code nicely separated.

Updating your local branch is

git checkout <local branch>

git merge master

or

git rebase [-i] master (will put your patches on top, but might give more merge problems)

if you do it interactive [-i] then you could also skip some of your old patches, what might be extremely usefull, if you know a corresponding solution was implemented to master

but unfortunately there is no way to avoid merging problems ;(

[Sealiah]

Okay, I'm really confused at this point (No Git experience)

Say for example I have a fresh core downloaded via Git. Fully compiled and everything

How exactly would I go about making it so that when I change something in the core, it will make a patch so that when I need to update my core, I can reapply all the patch files from changes I have made. Step-By-Step for a complete noob please. Exactly what I need to do and exactly what I need to type in.

Sorry for being such a pain and I really appreciate all the help guys.

[Schmoozerd]

for me https://mangos.lighthouseapp.com/projects/18208/contributing-made-easy

was very helpfull, and there are the nice vids and texts and http://book.git-scm.com/index.html

Also something about the philosophy and why git is cool: there is a google tech talk by linus torvalds, which is worth a look (linked here in one of the git stickies)

[Sealiah]

Alright. Thank you for the links.

However I'm still lost

The things I gleaned from those links are: Creating a repo, creating a branch. And... that's about it. I'm really confused about the rest : /

[Schmoozerd]

ah, sr, wrong link: https://mangos.lighthouseapp.com/projects/18208/sending-patches

Hm, I think I ll try to write down my usual workflow:

<Start in a clean clone, branch master>

git checkout -b NameOfTheGreatFeature

<now I am on branch NameOfTheGreatFeature>

<Hack in some Code>

git status <show what I did>

git add changedFile1

git add changedFile2

...

<or use commit -a to commit all changed (but not new) files>

git commit [-a] -m "A short msg what I did"

<Hack in even more Code>

..

git status

git add ..

git commit [-a] -m "I did more!"

...

<Oh, I missed some whitespace or a typo in my last commit>

<change it>

git add gile

git commit --amend

<Hm, there is a cool new feature submitted to origin, I want this!>

git checkout master

git pull

git checkout NameOfTheGreatFeature

<There are now two main ways to 'merge' my changes and master, merge and rebase>

<rebase rewrites history, which might be good, if you haven't published your changes>

<merge merges, which doesn't look so good, but keeps the history intact>

git rebase [-i] master

<or>

git merge master

<Edit conflicts>

<Now you have your branch with recent src-base, and your feature, including your own history>