Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 bugs buggy wrote: > Anyone have any opinions on what should be done? Another option: How about adding version checking stuff to 2.1.3 and then releasing 2.1.3 + some non-netcode fixes? When releasing 2.1.3 add information on our plans for 2.1.4 (see below) to the release announcement, so people are prepared. Not sure how version checking is achieved, but I hope that it is possible to implement version checking without breaking backwards-compatibility to 2.1.2. Perhaps some behaviour of versions prior to 2.1.3 could be used as an indicator. Then in 2.1.4 you could add that networking fix as 2.1.3 users have version checking and one should assume that most people upgraded to 2.1.3 in the meantime. More stable netplay would surely convince most people to use 2.1.4 anyway. - --> 2.1.4 will not work with 2.1.3 or any other version prior to 2.1.4. But that should be okay as the advantages people get in exchange for incompatibility should outweigh the disadvantages. More stable netplay was _the_ main goal for 2.1, so that sacrifice is justified. Eventually people will understand that. Yet another option (just to have mentioned that one as well) is to not use the fix for netplay (aka the unfixed netcode), if 2.1.3 or no version is detected. Dirty: Yes. Convenient for the users: Yes. Convenient for distributors: Yes. Going to a stable 2.2 ASAP could help with overcoming this "mess". P.S.: Everything's IMHO ;) - - Kreuvf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJu3im4y86f1GXLDwRAih7AJ9ovG9wI02t69WNMzgR3A4P8kMQnQCfRJBG 3vM7pOV5klowA0hQzzSWP5E= =G7Ik -END PGP SIGNATURE- ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Dissecting the NTW mod?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 bugs buggy wrote: > Also, I don't see any readme/authors file in that mod, so how can we > contact the original creators of the parts that are in it? > I don't see a changelog either, but I know it was updated? Delphinio has an account on my site, it's no problem for me to contact him. And afaik he has not that much experience using version control systems and is not used to the common way of doing things. I am quite sure that he will happily add the missing information once things have been explained to him. - - Kreuvf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJu3l44y86f1GXLDwRAhquAJ9JDoFYNk4lSh7zY5RspOsmZT0NgQCgllhX 2Nv8kqaAPKbdFM0dC07G7JY= =SbAj -END PGP SIGNATURE- ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Dissecting the NTW mod?
Am Samstag, 14. März 2009 10:31:38 schrieb Kreuvf: > bugs buggy wrote: > > Also, I don't see any readme/authors file in that mod, so how can we > > contact the original creators of the parts that are in it? > > I don't see a changelog either, but I know it was updated? > > Delphinio has an account on my site, it's no problem for me to contact him. > > And afaik he has not that much experience using version control systems and > is not used to the common way of doing things. I am quite sure that he will > happily add the missing information once things have been explained to him. There once was quite some readme file in there... I guess it got lost in the delete-and-update session. I agree with Kreuvf that he will likely help and provide what is needed if we teach him what is necessary. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
Am Samstag, 14. März 2009 10:28:10 schrieb Kreuvf: > bugs buggy wrote: > > Anyone have any opinions on what should be done? There comes something to my mind: If version checking is implemented in 2.1.3, it should be able to figure out that 2.1.2 (and prior) do not support a versioned network protocol. Thus it should be able to drop connections with people using that... It will be a little bit unexpected for those using 2.1.2, but if we explain this in the release notes, I think it will be less so. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
Am Samstag, 14. März 2009 02:55:26 schrieb bugs buggy: > On 3/13/09, Dennis Schridde wrote: > > Am Samstag, 14. März 2009 01:30:39 schrieb bugs buggy: > > > I mean, I know how git handles it, but how do external programs > > > handle this? > > > > Which external programs do you refer to? And which issue might they have? > > When you clone the repo at gitorius now, it has trunk, 2.2, lua, and > whatever else in it right? > > In the directory where you cloned to, it don't show 'trunk' / 'lua' or > whatever directory, it just shows what looks like a snapshot of trunk. > > Now, if I want to work with lua stuff, I can't do a 'cd lua' and see > all files there. I need to somehow export that (or clone the specific > branch) to a new directory, so it has all the files required to build > the lua branch. Then, I can work on it as normal. > Then, when I get done with the changes I have made in that new > directory, I push those changes back to the original cloned copy that > I did, and finally, push that upstream. > > Is that a bit clearer? Yes, it is, thanks! It is also not the common approach. Usually one does "git checkout " to set the current working copy to the other branch, then work on that, commit/stash/etc and later return to the original branch via "git checkout". --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
Hi all, I'm glad the "Ready for the switch to git?" email spawned a lively discussion, and that a lot of people tried to actually use git. Below are replies to different people, bundled together to prevent me from repeating myself: Zarel wrote: > 2009/3/13 Stephen Swaney > >> The ability to branch freely is great but without a primary location >> for the source keeping track of who is 'it' sounds difficult. How do >> we keep all the package maintainers connected to what is going on? >> > I echo this. Having a single repository makes sure conflicts get > resolved quickly. If we don't have that, then what do we have? Several > versions of Warzone, each incompatible with each other, and no way to > easily merge them? > That's the best part, we *do* have a way to easily merge them. Git is designed to make this easy. > I mean, I wouldn't mind having my local copy as a separate repo, but > it should be merged with trunk fairly quickly. In short, I prefer the > current way. > I think all active developers will fetch from everyone daily so we will have a smooth flow of commits. Despite everyone telling that it works I'm really curious myself how well it does. The central repository is a good fallback if it turns out not to. > In addition, Git doesn't have anywhere near as good a Windows GUI as > TortoiseSVN. I like being able to diff/blame/make-patch in around two > clicks. Committing is two clicks. Unless you only want to commit some > files, in which case it gives a list with a bunch of checkboxes. All > versioned files are checked by default, and there are buttons to check > all, none, or versioned only. > You definitely did not try git gui and gitk. You won't have to go to the commandline for your everyday tasks. - Right click on the folder with your repository -> git gui - Make some changes, click Rescan. - Click the icon in front of the changed files you want to commit, or click "Stage Changed" to add them all - Write a commit message in the textbox - Click commit When you want to push your commits: - Remote -> Push - Push For the blame: - Repository -> browse * files - Click a file I never used git gui, and I was able to figure it out quickly. Give it a try. Don't be afraid to ask, either in #warzone2100-dev or #git. (helpful people over there) Elio Gubser wrote: > I'd like to stick with svn. The only _really_ issue is buggy's > connection problems. We should only tackle this problem and not create > new ones with introducing a completely different vcs. > At least I am very happy with svn (and gna) > I really feel restricted by svn. (I probably already told everyone a few times). It feels like being stuck on windows when you are used to linux, like being stuck on ice without ice skates, like programming in Visual Basic, like eating soup without a spoon. (no offense to the people who regularly do these things, especially to the ones without a spoon) You might not yet feel the restrictions (yet), but in my opinion it is best to use the most powerful tool/language/vcs from the start, rather than waiting until you need it. It might take some time getting used to it, but when you need the complicated features at least you are ready for it. bugs buggy wrote: > Another Q, what are these (core.autocrlf & core.safecrlf ) supposed to > be set at? Svn tracks what they are (either CR or CR+LF), git don't > have this, so how do we know what to set these values at ? What > happens if some are CR and some are CR+LF? Or did Gerard fix this on > the initial repo dump? > I believe git internally uses LF, and you can ask it to convert it to another format when you checkout. It seems to work but you might have to do a git reset --hard (it's a scary name for a simple command) if git diff shows changes on all lines of all files. Regards, Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
We had something akin to what is described to the "git way" of doing version control in the Berlios days. Each developer wanting to do something was given his own branch, and then "someone" would somehow merge stuff for a release. It was a disaster. We need an official repository that everyone work up against, directly or indirectly, and unless I am mistaken, even the linux kernel has this. My impression is that git is good, and probably the future, but still a rather immature tool. Or maybe I and the other sceptics are the immature ones that just need more time to wrap our brains around it. Either way, I would like us to ask google for hosting for now. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
Hi all > My impression is that git is good, and probably the future, but still > a rather immature tool. Or maybe I and the other sceptics are the > immature ones that just need more time to wrap our brains around it. > Either way, I would like us to ask google for hosting for now. > > - Per +1 As far as i understand the 'git-way' needs a person who merges every developers commits togheter. Well I fear, with our current development activity and team size, this would produce a lot of overhead and bureaucracy for no big advantage. I believe it works well with the linux kernel. It's a lot bigger project and a lot more devs are working on it. So QA is more important as more commits are done and a lot of people are working with the same file or piece of code. But with our activity.. I can keep track what's going on easily with trac. regards elio ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
2009/3/14 Elio Gubser : > As far as i understand the 'git-way' needs a person who merges every > developers commits togheter. Well I fear, with our current development > activity and team size, this would produce a lot of overhead and > bureaucracy for no big advantage. This. (By the way, I sent the e-mail yesterday. No idea how long before I get a reply.) -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
Am Samstag, 14. März 2009 13:51:33 schrieb Per Inge Mathisen: > We need an official > repository that everyone work up against, directly or indirectly, and > unless I am mistaken, even the linux kernel has this. They used a shared repository? Do you have some docs on how they propose to deal with the merges & co? --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
On 3/14/09, Dennis Schridde wrote: > Am Samstag, 14. März 2009 10:28:10 schrieb Kreuvf: > > > bugs buggy wrote: > > > Anyone have any opinions on what should be done? > > There comes something to my mind: > If version checking is implemented in 2.1.3, it should be able to figure out > that 2.1.2 (and prior) do not support a versioned network protocol. Thus it > should be able to drop connections with people using that... > It will be a little bit unexpected for those using 2.1.2, but if we explain > this in the release notes, I think it will be less so. > Nope, it can't do that. 2.1.3 sends the 'version_check' message, but 2.1.2 has no idea what that messge is, and all we do is return false. No error or warning messages at all. :( ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
On Sat, Mar 14, 2009 at 4:03 PM, Dennis Schridde wrote: > Am Samstag, 14. März 2009 13:51:33 schrieb Per Inge Mathisen: >> We need an official >> repository that everyone work up against, directly or indirectly, and >> unless I am mistaken, even the linux kernel has this. > They used a shared repository? Do you have some docs on how they propose to > deal with the merges & co? Not a shared repository, but an official one that everyone sync against. I am a little bit confused by this discussion. I am not aware of any lacking support in git for shared repositories. I thought that was what 'git push' was all about. I am aware that the linux kernel does version control without a shared repository, but why do we need to even consider this possibility? We obviously do not have the manpower to work like they do. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
On Saturday, 14 March 2009 at 11:53, bugs buggy wrote: > On 3/14/09, Dennis Schridde wrote: > > Am Samstag, 14. März 2009 10:28:10 schrieb Kreuvf: > > > > > bugs buggy wrote: > > > > Anyone have any opinions on what should be done? > > > > There comes something to my mind: > > If version checking is implemented in 2.1.3, it should be able to figure > > out > > that 2.1.2 (and prior) do not support a versioned network protocol. Thus it > > should be able to drop connections with people using that... > > It will be a little bit unexpected for those using 2.1.2, but if we explain > > this in the release notes, I think it will be less so. > > > Nope, it can't do that. 2.1.3 sends the 'version_check' message, but > 2.1.2 has no idea what that messge is, and all we do is return false. > No error or warning messages at all. :( Could the version check be done in the lobby server? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
On 3/14/09, Christian Ohm wrote: > On Saturday, 14 March 2009 at 11:53, bugs buggy wrote: > > On 3/14/09, Dennis Schridde wrote: > > > Am Samstag, 14. März 2009 10:28:10 schrieb Kreuvf: > > > > > > > bugs buggy wrote: > > > > > Anyone have any opinions on what should be done? > > > > > > There comes something to my mind: > > > If version checking is implemented in 2.1.3, it should be able to > figure out > > > that 2.1.2 (and prior) do not support a versioned network protocol. > Thus it > > > should be able to drop connections with people using that... > > > It will be a little bit unexpected for those using 2.1.2, but if we > explain > > > this in the release notes, I think it will be less so. > > > > > Nope, it can't do that. 2.1.3 sends the 'version_check' message, but > > 2.1.2 has no idea what that messge is, and all we do is return false. > > No error or warning messages at all. :( > > > Could the version check be done in the lobby server? > I thought of that as well, but the GAMESTRUCT is a fixed size, and if we changed it, it will do screwy things to pre 2.1.3 clients. Unless of course, we have a different lobby servers for 2.1.3 & trunk/2.2 ? That could work. But that don't stop the problem of direct connecting via IPs. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
Am Samstag, 14. März 2009 16:53:21 schrieb bugs buggy: > On 3/14/09, Dennis Schridde wrote: > > Am Samstag, 14. März 2009 10:28:10 schrieb Kreuvf: > > > bugs buggy wrote: > > > > Anyone have any opinions on what should be done? > > > > There comes something to my mind: > > If version checking is implemented in 2.1.3, it should be able to figure > > out that 2.1.2 (and prior) do not support a versioned network protocol. > > Thus it should be able to drop connections with people using that... > > It will be a little bit unexpected for those using 2.1.2, but if we > > explain this in the release notes, I think it will be less so. > > Nope, it can't do that. 2.1.3 sends the 'version_check' message, but > 2.1.2 has no idea what that messge is, and all we do is return false. > No error or warning messages at all. :( The 2.1.3 client should figure out that it is talking to someone who does not understand what version_check means, shouldn't it? So the function could return a failed version check if it does not receive any answer at all. We could even signal to the user that client X does not support version_check and was thus removed from the game. Please tell me where the flaw is in that thought. --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
Am Samstag, 14. März 2009 16:55:03 schrieb Per Inge Mathisen: > On Sat, Mar 14, 2009 at 4:03 PM, Dennis Schridde wrote: > > Am Samstag, 14. März 2009 13:51:33 schrieb Per Inge Mathisen: > >> We need an official > >> repository that everyone work up against, directly or indirectly, and > >> unless I am mistaken, even the linux kernel has this. > > > > They used a shared repository? Do you have some docs on how they propose > > to deal with the merges & co? > > I am a little bit confused by this discussion. I am not aware of any > lacking support in git for shared repositories. I thought that was > what 'git push' was all about. It has the support, no doubt. But from my experience a shared repository creates an endless row of merge- commits, because everyone pulls, works, pulls again, merges, pushes. In a non- shared repository there would be a lot less merges, because you would pull more seldomly and only from a limited number of repositories. (It multiplicates when several people work on the same repository.) So while it is not impossible to work like that, it is more annoying. (And that is why it is not recommended either.) --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
On 3/14/09, Dennis Schridde wrote: > Am Samstag, 14. März 2009 16:53:21 schrieb bugs buggy: > > > On 3/14/09, Dennis Schridde wrote: > > > Am Samstag, 14. März 2009 10:28:10 schrieb Kreuvf: > > > > bugs buggy wrote: > > > > > Anyone have any opinions on what should be done? > > > > > > There comes something to my mind: > > > If version checking is implemented in 2.1.3, it should be able to figure > > > out that 2.1.2 (and prior) do not support a versioned network protocol. > > > Thus it should be able to drop connections with people using that... > > > It will be a little bit unexpected for those using 2.1.2, but if we > > > explain this in the release notes, I think it will be less so. > > > > Nope, it can't do that. 2.1.3 sends the 'version_check' message, but > > 2.1.2 has no idea what that messge is, and all we do is return false. > > No error or warning messages at all. :( > > The 2.1.3 client should figure out that it is talking to someone who does not > understand what version_check means, shouldn't it? So the function could > return a failed version check if it does not receive any answer at all. We > could even signal to the user that client X does not support version_check > and > was thus removed from the game. > Please tell me where the flaw is in that thought. > > --DevU > There is no flaw in that thought, after X (5 secs? 10?) if we don't get a echo back, we could kick... just means more coding. Something like host broadcasts "trunk", and after X, if we don't hear a reply, we kick? I'll try it and see how it goes. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
On Saturday, 14 March 2009 at 12:14, bugs buggy wrote: > On 3/14/09, Christian Ohm wrote: > > Could the version check be done in the lobby server? > > I thought of that as well, but the GAMESTRUCT is a fixed size, and if > we changed it, it will do screwy things to pre 2.1.3 clients. > Unless of course, we have a different lobby servers for 2.1.3 & > trunk/2.2 ? That could work. Hm, so the game sends a fixed struct to the lobbyserver, and every time the struct changes, both game and server have to be updated? Then I guess my idea wouldn't work, except if one of the fields could be abused to include the version information. A new lobby server instance (+ port) per network protocol change is not good. But Dennis's idea sounds better anyway. > But that don't stop the problem of direct connecting via IPs. Yeah, but people playing with direct IPs would have to communicate anyway, and those using 2.1.3+ would hopefully know about the network fix. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
Dump from IRC: Use a simple number (int), which we increment everytime we change the netcode in an incompatible way. Use a 2nd number in addition, which we increment if some compatible enhancement happens. (And reset when we increment the major version.) (That is in fact similar to what is done for shared objects on Linux.) Since we need to check game data and mods as well, strings seem better for that task. (Simply concat the version strings. Example: "trunk:aiv:ntw") They could be seperated from the netcode version though. Proposed constants: NETCODE_VERSION_MAJOR=0, NETCODE_VERSION_MINOR=0, DATA_VERSION="2.2" (With the latter being the one used to concat mod version strings onto.) --DevU signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
On Saturday, 14 March 2009 at 20:22, Dennis Schridde wrote: > Am Samstag, 14. März 2009 16:55:03 schrieb Per Inge Mathisen: > > On Sat, Mar 14, 2009 at 4:03 PM, Dennis Schridde wrote: > > > Am Samstag, 14. März 2009 13:51:33 schrieb Per Inge Mathisen: > > >> We need an official > > >> repository that everyone work up against, directly or indirectly, and > > >> unless I am mistaken, even the linux kernel has this. > > > > > > They used a shared repository? Do you have some docs on how they propose > > > to deal with the merges & co? > > > > I am a little bit confused by this discussion. I am not aware of any > > lacking support in git for shared repositories. I thought that was > > what 'git push' was all about. > It has the support, no doubt. > But from my experience a shared repository creates an endless row of merge- > commits, because everyone pulls, works, pulls again, merges, pushes. In a non- That could be avoided by rebasing instead of merging, I think. So you have pull, work, pull, rebase, push. As long as people only use the shared git tree, that should work. Once they start pulling from each other, things might get ugly, though. > shared repository there would be a lot less merges, because you would pull > more seldomly and only from a limited number of repositories. (It > multiplicates when several people work on the same repository.) > So while it is not impossible to work like that, it is more annoying. (And > that is why it is not recommended either.) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Release 2.2 (with port change) or go with 2.1.3 + port change or ?
Hi all, > Proposed constants: > NETCODE_VERSION_MAJOR=0, NETCODE_VERSION_MINOR=0, DATA_VERSION="2.2" > (With the latter being the one used to concat mod version strings onto.) I'd rather just use the SVN revision of the game. It is simpler. Furthermore there are a lot of changes we could make to the game that do not involve the netcode that could break stuff. My proposal: SVN revision, int, locally modified, bool (just issue a warning to both sides if any player has it as true), hash, string. For the moment I suggest that we make the hash just an empty string, but it will allow us, in the future to hash mods and compare game data, Of course, for the moment an empty hash makes more sense, time wise. This method is: - foolproof, as it handles accidental local modifications and game changes (stats etc, as different rev numbers); - simple, thanks to autorevision; - extendible to handle mod hashing in the future. Regards, Freddie. signature.asc Description: This is a digitally signed message part ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
