For the data file, you can also use a separate github repo (e.g. github.com/opendungeons/opendungeons-data) and use git submodules to reference the location of the mesh files into the main tree (github.com/opendungeons/opendungeons). One then has to clone the main repo and update the submodules to grab the game data. This way you can also upload the .blend files to github and link only the meshes as submodules (the main advantage would be to have everything at the same place).
It also makes it possible to provide the source code and the data separately for packaging purposes. It's especially useful if the game data is huge, since it can then be packaged (at least with RPM) as a architecture-independent package, so it is not duplicated in 32bit and 64bit repositories contrary to the game binary.
I support using git.
I’m not sure about using github, it being centralized and all. But I don’t really care, and as I won’t help putting anything else together I don’t really have that much to say about the hosting part.
I use it because you do But I agree it is pretty easy to use and have usefull tools.Bertram {l Wrote}:As a proof of everything stated above, hwoarangmy, MCMic and myself are already using my github fork as a reference and I only have the surplus work to resync with sourceforge from time to time.
I also think it would be a good thing to have only 1 repository to download to compile the sources. The more complex it is to download sources (I mean downloading dependencies, sources from different locations, ...), the less chances we have to get new coders/artists.Bertram {l Wrote}:Please note that I'm speaking of game data directly used by the engine, not their source files. I.e.: blend files can stay in the SVN media repo, while the mesh files are used by the engine and thus are part of the game data.
Bertram {l Wrote}: Sad that you're not planning to help anymore, though.
Bertram {l Wrote}:Akien {l Wrote}:It also makes it possible to provide the source code and the data separately for packaging purposes. It's especially useful if the game data is huge, since it can then be packaged (at least with RPM) as a architecture-independent package, so it is not duplicated in 32bit and 64bit repositories contrary to the game binary.
Hmm, I disagree there, since first it's the packager problem not the developer's one. (Owww, Bertram is sooo evilish. ;P) (joke). More seriously, the point is more about configuring cmake to create clean and different packages if packagers need it, more than splitting the packages by other means, in order to, once again, ease the developer's work. Also, OD is not some kind of engine aimed at only being used for total conversion but rather a full game. This means data is strongly linked to the current engine version and separating the engine from the data is only relevant for fixing the binary packages, which 99% of the time, triggers a fixed game data package anyway, or small engine bugfixes.
MCMic {l Wrote}:I was only talking about web hosting and organisation, I do plan to keep helping with coding when I can.
Archlich Akien {l Wrote}:But my argument was wrong, because I can create arch-dependent and arch-independent packages in the same source package, i.e. using the same source tarball. And then your argument that most of the time the source code changes, the data changes too, invalidates my whole point :P
Evil Bertram won the fight, but not the war! Archlich Akien will strike back!
hwoarangmy {l Wrote}:I use it because you do But I agree it is pretty easy to use and have usefull tools.
I have not enough experience to say if github is better than the others. But I played another open source game lately called UFO AI (a XCOM clone). They use git on source forge. They have a very large repository (more than 1Gb). And from what I read on their forum, they are not happy with SF. I have also tried to download their sources and it crashed several times. That being said, I don't know if there are similar problems on github with big repositories...
oln {l Wrote}:The main useful thing with sf.net has been the web hosting, though I suppose it wouldn't be that difficult to replace that either if there was a strong desire to move somewhere else.
Paul {l Wrote}:I don't mind changign to github or other source hosting site, if it is true that it would attract more people . I don't mind even if things get more complex.
Also : so your point is to move away entirely from the SOURCEFORGE , right ? What I can say, for me before joining OD it was a way of quickly monitoring what happens in the world of open source games .... but for now we cannot exceed 100 downloads / week , so maybe it's not a big lost ...
hwoarangmy {l Wrote}:I have not enough experience to say if github is better than the others. But I played another open source game lately called UFO AI (a XCOM clone). They use git on source forge. They have a very large repository (more than 1Gb). And from what I read on their forum, they are not happy with SF. I have also tried to download their sources and it crashed several times. That being said, I don't know if there are similar problems on github with big repositories...
How about moving the blend files to github too (in a subrepo, see for example what our neighbour does at https://github.com/stuntrally ), and use Sourceforge only to distribute source tarballs and compiled binaries?
I've seen many projects do this, it has the advantage that contributor don't have to learn how to use git + svn but can concentrate on git. I'm not a strong advocate of this though, I just wanted to add this possibility to the discussion.
The main advantage is that everything is in one place (github), though in separate repos (one repo for source code + meshes, one repo for assets source). I also experienced github to be more reliable than sourceforge to generate and download tarballs of the repos. On the other hand keeping the blends on SVN is not a bad choice either, because it's already there, and for such a repo you don't need a deep understanding of how SVN works (it's basically just checkout, add and commit that would be used).
[...]
I confirm that it's practically impossible to download big snapshots on Sourceforge, most of the time you have to do a good ol' svn checkout and generate your source tarball (direct download of upstream tarballs works fine though, it's only the "repo snapshot" function that is unreliable in my experience).
With github it works alright most of the time, the only thing that annoys me is that it proposes only to download zip files and not tarballs (but you can copy-paste the path to the zip file and change "zip" to "tar.gz" to get a tarball).
Bertram {l Wrote}:Feel free to update the SVN repo with whatever cleanups are needed and I'll import the media-source part afterwards. I'll also sync the OpenDungeons repo with the cleanup made on the media part. (The part about game data used directly by the engine.)
You are now an owner of the project OpenDungeons which gives you the possibility to destroy anything, so please take care.
*Glup* Ok...
Lets go slowly then... ill clean the SVN repo first, do i need permission as well to do it or is it the same user as Github?;
once thats done you will sinc SVN with Github and i can add(pull request) models directly to "openDungeons repo" or "media source", being media source kinda my playground. Is that all correct?
Users browsing this forum: No registered users and 1 guest