freghar

That should turn off any CRLF/LF conversion, ie. you will have LFs even using msysgit. That's normally not a problem for anything except notepad.exe.

With msysgit using autocrlf=true, all CRLFs should be converted to LFs in the repo. Ie. you'll still see CRLFs in the working tree, but only LFs will be in the object database (and thus only LFs gets distributed). (from my own little experience with msysgit on winXP, remote repo had all LFs, my working tree had all CRLFs, patch application may screw this a bit, though)

That highly depends on the CPU scheduler, with less than 200 threads, it should be pretty much fine on today's average machine. The switching overhead rises a bit somewhere around this "limit", but it's nothing really bad, 400 threads are like 400 processes (from the scheduler's point of view), which is roughly 10 processes per user for 40 users and many thin-client servers live with that. Moreover, the CFS scheduler is able to scale to even 4096 CPUs without much overhead, so the problem is rather theoretical on most modern OSes (I saw some improvements in this for BSD kernel + I guess that Windows server editions have thread management improved as well). On the other hand, we really don't need this. To implement a thread-kill feature, we don't need to have a thread. Each of those threads processes some map - if we move this processing to a pool of threads, each thread will process more or less atomic pieces of the data. If an error occur, the current processing thread can either free all instance resources, causing the same effect as thread kill, or just schedule this task for another time. And yes, I disagree with the "if something goes wrong, we need to segfault the server". There are many places where memory corruption may occur, but we should make sure that it isn't in the main process handling functions - ie. thread management. Even if it takes memory checksums (as I've seen elsewhere). Separating each instance of a map to new thread wouldn't help us, since threads share memory addressing space. Thus you _can_ corrupt any piece of stack in the program from any thread. .. just my 3 cents

Pretty much, yea. Other than that, you look like another nice I-wanna-be-smart spambot.

Yes, it's possible, but not that easy. Search how wikileaks server is "mirrored" to get the idea. Ie. http://wikileaks.org/wiki/Wikileaks:About#What_is_Wikileaks.3F_How_does_Wikileaks_operate.3F and http://wikileaks.org/wiki/Wikileaks:About#Is_Wikileaks_accessible_across_the_globe_or_do_oppressive_regimes_in_certain_countries_block_the_site.3F for starters.

That would, in fact, only help him with conflict resolution, it has no chance to resolve the conflicts as git-am (and git-apply IIRC too) does exactly that if a simple patch application fail. See that "index c024989..e0e10fc 100644" line in each diff. The first hash is the original (unpatched) file blob. If patch apply fails, git tries to reconstruct an original unpatched tree using those hashes, applies the patch to it and goes for several classic merge strategies (since it now has 2 trees).

First, yes, it's possible to add them as remotes, preferably editing the fetch line in .git/config, so they're able to share references, but it's often really not needed, only if some mirror is offline, which isn't going to happen that often. Secondly, please read something about git-pull, it somewhat differs from fetch, making the merge in your solution useless.

I've set-up several git mirrors of the github repository, partly because of the DDoSes, partly to balance the github load. They are updated every full hour, you can use them instead of git://github.com/mangos/mangos.git , they are in fact faster most of the time (I got 4MB/s download from gitorious). git://git.assembla.com/mangos-mirror.git git://gitorious.org/mangos-mirror/mangos-mirror.git git://mangos-mirror.git.sourceforge.net/gitroot/mangos-mirror/mangos-mirror ... and to help some people behind firewalls ... http://git.gitorious.org/mangos-mirror/mangos-mirror.git And that's it! Well, some bonus stuff below. ---------------------------------------------------------------------------------- Checking mirror's valididy You shouldn't have any need to do this, it's just one of the options that multiple mirrors allow you to do. Since git was designed as distributed SCM, it has some of these checks by design. The most visible one is SHA1 hash. You can clone (for example) two mirrors and then compare their HEAD. If both hashes are the same, you either have a valid repo .. or both mirrors were compromised. Note that smart people don't actually need to clone another copy, they just fetch from the other URI and if nothing gets fetched, they know both repos are basically the same. You can do this check with github.com itself, but bear in mind that a new commit might have been pushed there and mirrors are a few minutes behind (which makes you receive two different HEADs) .. so do it by hand (git log -1 origin/master and search github.com website for that hash). Please note that you REALLY don't need to do this unless you are 110% paranoid or "just want to give it a shot". Github down, but I want to update That's fairly easy, if you are the "git pull" person, instead of using git pull or git pull origin master replace the "origin" by mirror URI: git pull git://some.mirror.org/mangos-mirror.git master (feel free to replace "master" by "mangos-0.12" or anything like that) If you are the "git fetch + merge/rebase" person, instead of git fetch origin git rebase origin/master try this: git fetch git://some.mirror.org/mangos-mirror.git master git rebase FETCH_HEAD (there's no FETCH_HEAD/master, if you want both master and mangos-0.12, you need to fetch them separately, FETCH_HEAD is in fact .git/FETCH_HEAD file and it always contains last fetched HEAD, which is master in this case) Once github.com (or your favorite mirror) is back online, you can update as usual.

Obviously, the patch does not apply. You probably have incompatible patch<->source versions.

Yeah, but it seems they have a problem with something, anyway - use http://repo.or.cz/r/getmangos.git , it works for me.

Here I am. As usual, annotated tag object d7237e4 called v0.14 created, pointing to commit object f5025e3 ([8587] MaNGOS 0.14 release.). $ git tag -ln v0.12 MaNGOS 0.12 v0.13 MaNGOS 0.13 -- moving from client 3.0.9 v0.13-dev1 MaNGOS 0.13 dev1 -- moving from client 3.0.3 v0.13-dev2 MaNGOS 0.13 dev2 -- moving from client 3.0.8a v0.14 MaNGOS 0.14 -- moving from client 3.1.3

I have no idea why you can't just compile them in place, without any copying, but yes, it should work as expected.

Since a tag is static _forever_, it makes no sense to fetch it more than once, making the line meaningless. tag v0.13-dev1 will always point to the commit which it is pointing now.So the cleaner way would be to fetch the tag and create a new local branch with the tag's commit as a base. git fetch mangos-0.13.303 refs/tags/v0.13-dev1 git branch working v0.13-dev1 git checkout working or something like that. You can sometime later use "v0.13-dev1" again, without any need for special fetch lines in .git/config. To make the life of svn-like users easier, git checkouts the working tree on many operations. When you merge, it creates a merge commit and checkouts it to working tree. When you apply a patch, the change exists ONLY in working tree (= files and folders) until you commit it to the virtual filesystem.So for the most part, I wouldn't fear about anything being unavailable in the working tree. And just btw .. I can recommend http://eagain.net/articles/git-for-computer-scientists/ for some basic knowledge about git objects.

... if I may link it here ... http://mangosclient.org/

Again, a lot of things were mixed together. Sorry, I haven't another two hours to split correctly your post and do proper inline quoting, so bad this isn't a mail. Thus I'll try to explain things by references. Wrong. An empty working tree. The working tree is "all the files and folders you can see". It's only a minor part of the repository, all the magic is stored underground in .git/ and the working tree can be created using objects in it, completely offline. Yep. Because pull is trying to be smart. That's why I excluded it. Let me explain my version a bit: * git init - init an empty repository, no branches, no remotes, no master, no origin, nothing * git remote add -f -t mangos-0.12 origin git://github.com/mangos/mangos.git - add new remote named "origin", track only mangos-0.12 refspec (NO relation to local branches and their tracking, this is just "what to fetch" thing - it also applies to future fetches/pulls .. thus you can't ever download anything else (besides mangos-0.12 refspec) from origin unless you explicitly state so) .. and fetch (-f) from it. I've added the fetch here, so it automatically creates origin/mangos-0.12 remote branch ("remote" means .git/refs/remotes, not that it's stored somewhere else) and thus you don't have to do "git fetch origin" in another step. You can, though. It's an analogy to pull (which is fetch+merge). * git branch master --track origin/mangos-0.12 - create a new local "master" branch and set up a tracking entry for the origin/mangos-0.12 refspec. You can do something like "git branch woot --track master" and everytime you write "git pull" while being on the "woo" branch, you'll automatically merge your local master. As explained in my previous post, this is the "true" tracking. The git-remote thing is actually a nice hack (which I'll show you in a minute), nothing more. * git checkout master - checkout the newly created master branch, thus creating all the files and folders you already know. Checkout actually means "throw all files from this refspec to my working tree". The feeling of moving over branches is just feeling and a small asterisk character in git-branch's output (and git-commit's ability to determine where to put a new commit). Now - what advantage have this way over yours? It sets up a branch tracking entry (the --track). It's useless for me, since I feel more safe when explicitly stating source and destination, but it provides some kind of confort to most people. Branch tracking looks like this: [branch "master"] remote = origin merge = refs/heads/mangos-0.12 It tells the git-pull to automatically fetch "refs/heads/mangos-0.12" refspec from origin whenever is git-pull called without arguments and merge it with your current branch, all this only if your current branch is named master and you're "on" it right now. An example: I want to merge my branch with an upstream branch. I've my local branch checkouted (I'm "on" it) and already set up a branch tracking entry, like the one above. I can: git fetch origin refs/heads/mangos-0.12 git merge origin/mangos-0.12 OR simply git pull As you can see, in the second example, no arguments were needed. This and only this is the purpose of tracking branches. The comfort. Nothing more. Now take a look what the manpage calls "remote tracking": [remote "origin"] url = git://github.com/mangos/mangos.git fetch = +refs/heads/mangos-0.12:refs/remotes/origin/mangos-0.12 fetch = +refs/heads/master:refs/remotes/origin/master It says that whenever I type "git fetch origin", it downloads ONLY refs/heads/mangos-0.12 + refs/heads/master (those are paths on the remote side) and stores them to my local hierarchy, under refs/remotes/origin/mangos-0.12 and refs/remotes/origin/master, respectively. When you specify just "git remote add moron git://github.com/whoever/somerepo.git", the entry looks like [remote "origin"] url = git://github.com/mangos/mangos.git fetch = +refs/heads/*:refs/remotes/origin/* meaning that it downloads anything from refs/heads/ (on the other side) and stores it under the same name in refs/remotes/origin/ (== .git/refs/remotes/origin/) .. which usually means "fetch any branches the remote side have". Local branches are under refs/heads/my_branch, remote branches under refs/remotes/<name>/their_branch. Thus in both examples, you fetch ONLY remote side's local branches and tell git to store them as your remote branches. This is the default. The above example is what I called "the git-remote tracking hack" few paragraphs before it. As you see, it's a nice "hacky" usage of the "what to fetch" mechanism. The important thing is that the git-remote's "tracking" is actually useful, while the git-branch's "tracking" gives only a small comfort. So, that's "why tracking won't be like tracking". It isn't smart to use git-pull if you don't have any branch (because it will treat you as a very stupid user and create the master branch for you, which you might not want), furthermore, even if you'd had master branch already, using "git pull" would simply pull from the branch¨s tracking entry in .git/config, not from the remote. You either need to "git pull origin mangos-0.12" to fetch+merge origin/mangos-0.12 into current branch, or simply "git fetch origin" to fetch everything specified by the "fetch=" line for the given remote in .git/config (which is "fetch = +refs/heads/*:refs/remotes/origin/*" by default). I believe it's explained in some tutorials, I probably had some paragraph about it in the second chapter or my gitlog ( http://repo.or.cz/w/gitlog.git?a=tree;f=html;hb=master - click "raw" ). Simply - to be able to use any refspec, you need to have it locally downloaded. Yes, even "remote branches" (the moron/alpha thing) are stored locally. So you need to fetch first. Git-remote is just creating the [remote "moron"] section in .git/config and empty directory in .git/refs/remotes. Nothing more. Really.With the -f argument, it calls "git fetch <remotename>" as well, but that's optional. The -t argument simply modifies/adds a fetch line under that [remote "moron"] section. There's really no magic or anything with "master". Even if you probably don't realize it, adding -f to the git-remote line would solve your problem. Or doing it separately - "git fetch reno" before calling git-branch. See two quotes above. Nothing personal, but set-head is pretty advanced command, it's main usage is during mirror tweaking, which is, I believe, not your goal. Furthermore, it's unrelated to anything we're doing here. Uhh, a bit confused here. HEAD is HEAD. That's the refspec you're "on" right now. "git checkout master" and your HEAD == master. Something like "git reset --soft master@{2.days.ago}" and your HEAD points to that commit. See .git/HEAD.It has several meanings, not just this one. The set-head works with it as well. It allows you to select a specific branch to be checkouted on the client's side when client clones your repo, instead of "master", which is the default. ... and many other things. Well I think that at least the "tracking branches" are very well explained in all 42 tutorials I'm aware of, I simply explained it here just because of the (only by name!) relation to so-called "tracking" remotes.I might have moved the quotes out of the original context (and shifted them a bit), sorry for that. I'd suggest you some of the outdated links I have in my first gitlog chapter (pick chapter 01 - http://repo.or.cz/w/gitlog.git?a=tree;f=html;hb=master - again, the "raw" at end of the line).

Okay, as I see from the things below, you did some search, read some manpages and that kind of stuff. Let me see what I can do for you. It's in fact a lot easier to actually keep patches in commits. Say I have 10 patches, each in separate commit. When I want to update the sources, I simply rebase. All patches will be re-applied on the top of the new tree. If some of them fails to apply, you can fix the conflict and --continue, saving the resolved state. You can also --skip the patch or completely --abort the rebase, going back to the last stable state. It's also easily possible to move the commits (their "apply order"), add one between some other two, split a commit or melt several into one. Search for interactive rebase if you're interested. Indeed you did. But it's not perfect, plain "git pull" won't work, because the local master branch (which is a reflection of remote mangos-0.12 branch) wasn't set to actually track origin/mangos-0.12.So it should be: Creating another branch for your custom work is also useless. We just created your local "master". Any modifications to it will only affect your repository on your hard drive. Nothing more. (unless you push)To verify it, you can run git log --pretty=oneline -1 master git log --pretty=oneline -1 origin/mangos-0.12 If both hashes are the same, you have an exact "copy". I think you're missing a point here. checkout -b created a new local branch named "alterac", a copy of the master. Then git-remote added "alterac" remote (which isn't branch, it's an .. alias for certain remote path/URI), tracking only alterac-0.12 remote branch.Now this needs some explanation. Tracking in git-remote's meaning is "download only this refspec (= reference specification = branch,tag,hash,etc.) when a fetch-like command is issued. Nothing more. Tracking in git-branch's meaning is to allow "git pull" without specifying a source from where to pull. It's stored in .git/config. If you read the manpage of git-remote, you might know that remote -t allows you to track more than one branch. That's what remotes are for. Say I want all branches from repository called "moron" (which is my local alias for it) with public URI of git://github.com/NoFantasy/mangos.git: git remote add moron git://github.com/NoFantasy/mangos.git git fetch moron Now git-branch -a should display something like: * master remotes/moron/alpha remotes/moron/beta remotes/moron/gamma remotes/moron/whatever All those branches were downloaded and stored as "remote branches". See, there's a lot of redundancy in the git world. They, however, shall take only a few bytes if there aren't any massive differencies between them as git uses deltas whenever possible. If you want only alpha and gamma branches (since you care about those few bytes, because it's about 6MB with mangos/master<-->mangos/mangos-0.12), you can use git remote add -t alpha -t gamma moron git://github.com/NoFantasy/mangos.git I don't know how to add/delete branches from this list using git-remote, I simply use text editor and .git/config. There are fetch lines in "moron" remote section, cleverly using the "what to fetch" mechanism (for example, you would use refs/*:refs/* for a mirror). Okay, back on topic. From what I've said above, you should now see the error. git-remote isn't git-branchLocal branches can be specified using just their name (when there's nothing using that name), remote branches needs to be prefixed with a remote name they're stored under. My local master branch can be specified as "master", "heads/master", "refs/heads/master". You can have a tag with "master" name, which makes you unable to use "master", so at least "heads/master" and "tags/master" is needed. All names mentioned here (like refs, heads, remotes, tags, ..) have their directory representation in .git/ directory. It's quite interesting to see the structure, list through it if interested. And where my post ends.Oh, and ... One branch with several patches stacked up is good for your own (and simple) patches. When you're applying someone else's complicated patch, it's best to pull (or fetch+merge). It shall connect both trees and create a merge commit.To update the sources, you have to, however, hard-reset your master to a completely clean state (= latest upstream head, ... simply the commit you want to update to) and then re-pull everything. During the time your repository did nothing, others might have produced a better code in their remote branches, updated it to newer releases and such kinds of things. Note that git again downloads only differencies, things changed since your last pull. I personally have my branch with stacked-up patches which I keep rebased, several branches with bigger things that need multicommit changes and a master branch. When I want to update, I hard reset my master to something like origin/master (that's why you don't have to keep local master clean all the time) and then merge all my branches to master. It's actually an octupus merge of (right now) 8 trees, but that shouldn't bother you. Note that you can use several git-pull calls without any relation to hard reset. You have to be an upstream maintaiiner, though. You can, as said before, have several branches in one remote and several remotes in one repository. Having separate repositories would greatly increase your disk space usage (and bandwidth), since several repositories can't easily share objects between remotes and branches. Ugh, that was a long post.

I know only about #mmorpg-dev on freenode ..

Consider using git show -s --pretty=format:'%h' HEAD (substitute %h with anything you want (from the git-show's manpage).

Since the developers are now using my tool to backport commits from master to mangos-0.12 (and elsewhere), it should be possible to specify the commit as [1234] ie. git reset --hard [9000] (which works on recent commits, older ones were cherry-picked which left the number there) Only commits in the master branch should have those numbers. And yes, developers add the number there using Wyk3d's "git_id" tool. I'm not really a big fan of it, but as long as it makes their work easier, I don't care.

Note that the compression is also related to client machines. Maximum compression will need faster CPUs on players' machines while needing lower bandwidth, low compression speaks for the opposite.

CentOS 5.x uses custom kernel based on the Linux 2.6.18 one. IIRC only drivers and such things are "backported", so it shouldn't affect userspace that much to be important here.

Civ 3 model = ?

Actually, I think this particular case is broken on UDB too. At least it's broken in my UDB-based DB, I didn't change anything in that quest, others work just fine. I had similar problem with trial of the lake (combining two pendants) - I spawned the GO, it worked. After server restart, it was deleted, even though it was in the DB before (clean) restart. Not that I can provide any useful debug info, but it may very well be a 0.12 regression.

Since you opened this thread - I said it before and I say it again; mangos should have IMHO only account and character level bans. Just because the server is on application layer. I really doubt the official client uses specific TCP/IP implementation, you can probably connect with it via IPX link. The same should be true for mangos, it shouldn't care about the network (layer 3 and lower in ISO/OSI model), libraries can do that. I mean - the MAC thing is link-layer-specific, not all devices use the classic 14byte ethernet header, same applies to IP or any other layer3 protocol, unless the client sends it's IPv4 address explicitly in TCP payload (hell we shouldn't even rely on TCP, mangos' only interest is the network packet data, not headers). Yes, there can be situations where you need to ban someone without admin access, those situations might be rare though. I don't know whether the subhuman's link is some kind of P2P proxy, if it is, that's one of the solutions. No root / admin rights are needed (simply don't install it globally, use local structure), it simply serves as transparent proxy. If it isn't, you can write yourself a one. A simple IP relay (in -> check -> listening socket) should do the trick. However in case of a packet flood, it's better to filter those in the kernel.

Actually, I was working exactly on this (using code_swarm), but mangos has too short history, few large commits rather than tons of smaller. That doesn't really matter, but all projects visualized via code_swarm have history since .. 1994 or so .. and that's a sh*tload of commits to visualize. That isn't the case of mangos though.