Horde3D

I think we should discuss about the VCS and issue management: how could we improve the community feedback on this side?

IMHO, a switch to a Github (or Gitorious, or ...) repo should solve these two issues in one move: giving a more collaborative infrastructure to contribute to the code base and a solid issue management platform, for free.

About the eternal SVN vs Git problem, well, before I also didn't like Git, but now I find it very successful in open projects following this kind of working model:

http://nvie.com/posts/a-successful-git-branching-model/

Well, I have no doubt git is a great thing in theory, but usability is IMHO a pain in the ass. But Ok, I consider myself still young, so let's try something new:
Here we go: https://github.com/Volki21/Horde3D/tree/develop

Maybe I should have choosen a more official user name, but we might change that later too, since I won't publish any news about a new official git repository until I have merged at least one community pull request by using git.

@ Volker and attila

One of you guys should fork other ones repository, so other one can easily pull changes from other one or issue pull requests. I don't know, you two should discuss it.

I thought I may be able to create a new feature branch, that tracks the git repo from attila. I found some documentation how that may be possible under
http://stackoverflow.com/questions/1683531/how-to-import-existing-git-repository-into-another and http://stackoverflow.com/questions/1184518/getting-existing-git-branches-to-track-remote-branches, but couldn't find out, how that may be realized on GitHub.

I will fork Volker's official github repository ( and add a gles_d3d11 branch there). I have added a link in attila/Horde3D/read to the official repo. Possibly attila/horde3d-x should be removed in the future to avoid confusion.

Alright thanks attila. Makes things much simpler for me

Start using SourceTree or TortoiseGit or Gitg mixed with a terminal The main thing that I had pains with in the beginning is the modified work flow:
git clone = svn checkout
git commit -a -m "Message" = svn commit, but in a local sense!
git pull --rebase (rebase cleans the history by putting local commits "on top") = svn update
git push = upload your changes (aka svn commit ^^) to the main repository

Useful used-once-a-week work flows:
git stash, git stash pop = save your work without committing it, so you can switch branches or pull from the origin repository
git checkout [-b] feature_branch = svn copy/branch, but VERY fast. I use it for any ticket larger than 3-4 commits
git merge feature_branch = svn merge, but again VERY fast

You'd start to like it sooner or later, as it can do things in a snap, where Subversion would drive you crazy (branching, bisecting, cherry picking, ...)

Regards,
Christoph

Initial attempt to create a new README.md - the feature list is still too big for my taste. Other than that I like it. A paragraph about versioning should be added (how about SemVer 2.0?).

Thanks Christoph. Can you create a pull request for merge into develop branch?

BTW: I renamed my username to a bit more official one. I thought it might be better doing that before more people clone this repo. I hope that does not introduce to much trouble for attila and you when updating your forks.

Done.


As long as you don't force push there won't be any problems, because each commit has an immutable, unique hash. Git needs to be kernel-developer proof after all

Edit: Shall we move from MediaWiki to GitHub Wiki? Its easier to use, but less powerful (GitHub Markdown vs. WikiCreole).

Merged it, thanks Christoph.

Regarding the Wiki, I don't want to move to github. Personally I like the style of the wiki pages we have and don't want to add additional work of moving all the stuff to GitHub wiki. Another reason is that the Wiki pages here are easier to manage regarding the user administration, backup, customization etc, as we host it ourselfs and have the link to the phpbb forum software.

Yeah, I also prefer to stay on MediaWiki (honestly I don't really like it too much due to its forced Wikipedia-style, but in this case it allows more integration with official forum and avoids confusion).

Ok. An upgrade wouldn't hurt though, as the usability improvements over the last 3 years will simplify things.

I've tried to modernize the Wiki a bit last year (topic), but I failed due to template mess and time passing by Reviewing pages will take days and is very non-rewarding, as the Wiki doesn't feel like a first class citizen (mainly due to the homepage and way its integrated).

You mean an upgrade of the mediawiki version? I can try to update it when I'm at home again.

Regarding Git, I still hate it. I tried merging a pull request into master, but I'm really confused about, merging/cherry-picking/rebase and all this stuff.

I hope the way I did it is not the complete wrong one, and master is now on the same state as develop except the Animation method changes by Zuckk, that I'm still not completly convinced of.

I guess the README.md changes could be also merged into one commit, but I don't have the time to do that all by myself now until I get more familiar with git.

I think there's no need to hurry in pulling merge requests.

GitHub offers a good tool for merge discussion, so if we have doubts, we can discuss there and modify the merge to solve all the issues.