mackwic

Simply because it works for everyone including the programmers. Tools are already configured for that, git offers a full compatibility, so why change ? Why spending manpower in something we don't need ?

And why don't just inspire a bit from the cathedral model ? In the actual workflow, there is two componnents : our local repo and the svn master repo. Commit are applied with the Trac system. Robust, but a bit heavy. In the workflow I suggest, there is three: our local, the svn that becomes a "blessed" repo, and the repo of the team. Contributions follows 3 steps: ...... Step 1 : git svn fetch origin (aKa the bare repo) && git checkout -b {feature, fix}-<subject_of_feature_or_number_of_fix> We fetch the blessed repo without touching it and immediately create our own branch that's work on the specific goal we want to achieve. For example, we want to add a nice control for the unit groups, we can our branch "feature-group_controller". If the goal is to fix the bug #D43D5734K, let's create the branche "fix-D43D5734K". It's part of a common workflow very well explained here : http://nvie.com/post...ranching-model/ The branching model has another advantage that come in step 2. ...... Step 2 : git push {feature, fix}-<name_of_feature_or_fix> team_repo We push our contribs to the repo of the team in a new branch, not in master. Why ? Because it permits: better understanding of the state of the commits : one branch, one name. Easy to follow the progression of the work on a specific stuff (better that the diff viewer) easier to pack commits : the team make a commit of merging. That commit explains wich bug is related, wich feature is added. If not stable, open a ticket, reverse, fix it. It it's stable, go to step 3 ...... Step 3 : The team push the new stuff in master to the blessed repo so everyone can fetch it ...... Step 4 : go to step 1 You can use the illustration I make for a better understanding. The benefits of this model are: every developper can use the advantages of git the team can use the system of light-branching of git to organize the patches don't touch anything that actually works (it's an important point) let the artist team commit to the svn repo because that will never break the game (the work is less critical) less noise on the blessed repo (I think it's also an important point) improve the quality of the blessed repo code base I have to detail this last point. My point of view, as a programmer, is that the code quality of 0ad is very good and the game is exceptionnaly stable for an Alpha. As a programmer. But, we have to keep in mind that not only programmers use the svn version but also gamers. Do they all think that 0ad is stable enough ? Adding this step will permit to handle the future with bigger demands and larger audience, where everyone doesn't have in mind that 0ad is in Alpha stage. What do you think of that ? workflow_0ad.pdf

Nowaday, in Atlas, all in your FOV is always shown. If you have a very far zoom and display all the map, *ALL* vertices will be send to your graphic card. Even the chickens, that are far too little to be seen. Don't you think it would be a great improvement to display only entities with size of the same order of magnitude that our zoom ? Obviously, for long-term planing, we can extend this idea for the game itself. The same idea works too for particles (yes for huge smoke, no for little camp fire), for floor texturing (what about a simplification: if there is too little square of grass on the snow, display only the snow), for animations, etc. All modern 3D RTS have a detail precision depending of your zoom. Even if it's not the priority, 0ad should have it too.