Hi Torsten.
I can't see how Israels suggestion helps.
Thanks for your rebutal on
http://forum.flightgear.org/viewtopic.p ... 48#p263671Hopefully that is a path for me to explain my points of view. And hopefully you can consider the situation with a bit openmind.
Our scenery is alread modular
Well. Yes and No. The scenery itself is not modular. You distribute parts of it and compile it in a non modular set.
This would requires lots of confusing paragraphs to explain. So I'll go with 1 image == 1000 words thing here
This is how FG scenery looks like, and the underlying structure coded to be understood by the core
Now. When I mean modular, I mean that inside the Flightgear scenery directory, the content could be not the scenery directly, but a collection of Modules. Each directory inside could be a complete scenery package for a much much more small scenery package (a tile of 10x10 degrees, or a custom scenery, per example) Each of this directories are seen below with the letter M indicating they are actually scenery modules. Very similar as how the Aircraft directory actually contains subdirectories, each of them being one aircraft.
So, although you say FG Scenery is modular, it is not as modular as it could be convenient in order to split it effectively in smaller more manageable chunks (with ease).
Does anybody seriously considers keeping more than 50.000 revisions of scenery locally
well. First of all, that is something to be decided individually. It is not to the core developers to decide for all users how much of the total revisions we can be willing or capable to have. But more importantly, 1) a new refactoring of scenery can start again from "initial commit" (revision 1 if you which). Past is past now. 2) secondly, if every Module as shown above where separated, each of them will have a completely different "history". Frankly, I doubt everyone of them will accumulate 50000 revisions. that will mean our world got REALLY REALLY complete. and thus at the end a reason to celebrate.
3) Git has options to have a
shallow clone, which allow reducing the depth cloned at a given time to manage this situation. and 4)
More importantly, if we were to use github, an option to
fetch the git sceneries via SVN exist.
Also, you are no longer backward compatible.
Yes and no.
In fact, each individual module is (would be) backward compatible. We do it all the time when we create custom sceneries and point flightgear there as --fg-scenery.
I consider this an abuse of gitXXX. At least github asks to keep repositories under 1GB
Indeed I found this to be concerning before. Firstly, Gitlab had grown its individual repository size allowance to 10 G. And Github allows 1G.
As far as I am informed no single 10x10 degree tile in our whole world scenery approaches the 1G limit. Not even remotely.
A few months back I actually addressed github with the exact concern of having lets say 500 additional repos that exceeded 100 GB of content. As you are aware I have hosted the FG aircraft. a total of 700 repos counting for about 25 GB of data, and no concern by Github have been raised, but I worried about scenery being too large of a package. The answer by github was
Which indicated to me that hosting such scenery, if no single repo exceeds 1GB was not a violation of their TOS, and they would be calm about it.
Keep in mind that in terms of hosting, it is better to have 600 repos of half a gig each than to have 1 repo of 200 G total. Modularity pays off a great deal with computing.
We have a way to use distributed scenery by providing reverse proxies. People can submit updates to scenery models to the scenemodel db using the web interface. Those updates get reviewed by a human and applied. Using git patches for the workflow might be possible but does not help in our situation.
I am aware of it. I used it. And it has been O.K.
But I am certain that the possibility of submitting pull requests with scenery improvements will be an step forward from this situation. It gives lots of much flexibility. It also allows for human revisions (git pull requests are not forced writes!).
Furthermore, it will allow us to submit pull request for changes like new groundnets, new tower.xml or jetways.xml configurations, in addition to just add new models. It gives us major power in customizing the scenery. It allows us also to submit scenery that is currently unsubmittable via the db, such as OSM2City outputs.
As far as my understanding of the scenery building process goes, this is not as easy as it looks
Granted it is not. But it is my opinion that enhancing the ability to patch scenery with new layouts "on the fly" is a clever way to go (objective to aim).
And I understand work is being done in this direction.
but, modularizing the scenery will be a major advantage is being able to modify smaller tile sizes as well. Maybe reconstructing a 1x1 degree as needed and submitting the commit via Pull Request, which would be modifying only a 10x10 degree tile scenery repo -- not a whole world repo.
Just food for thought.
Thanks a lot for your attention,
IH-COL
