Dear Everyone, I hope this is the last time we will have to discuss this topic, since over the last months it seemed that everyone agreed with that FGDATA
- has to be split sometime - should be split a.s.a.p. We agreed that after the current release of 2.4 would be a good point to get the project on the way. As I offered and it still stands, I will take care of writing the bash script which "splits" the current FGDATA repository into multiple repositories and leaves an FGDATA repository which holds merely the bare essentials which supplement the core binary of fgfs. One could classify the contents of the new FGDATA by saying that it's data which provides the technical backbone - the common denominator everything is based upon. I'd like to cease this opportunity to give everyone the chance to utter their possible disagreement with the project or their respective opinions and discuss the very details of the split, which have not yet been determined. The general boundary conditions of the splitting process are the following: - FGDATA shall consist of everything which is essential for the binary to run and shall not hold any data which is specific to certain airports or airplanes. Those should be provided in separate repositories the structure of which is not of current interest and might possibly be chosen by the respective authors. - The change shall not require restructuring of the architecture, including the directory structure. Solely the repositories in which the data is contained shall change. Informatively, I'd like to supply a sensible suggestion for how a final structure might look and how, either as a developer or user might use it. Particularily, because some of you might wonder how we can strip FGDATA of KSFO and the 172p, leaving nothing to fly with - isn't that a bad decision? Definitly not. One has to distinguish between a proper, dedicated development structure which is aligned to and substructred into independent development units and a way of deployment. As a developer, you will clone the base fgfs SC repository and you will clone the FGDATA repository. Then, depending on your field of interest you will clone the aircrafts, airports etc. you are planning to work on. You can do so with the git submodule, which will integrate the specific aircraft/airport/etc repository into the existing FGDATA repository, while keeping the commits separate. For deployment, you either manually or programatically git-submodule all data required for shipping into a branch for deployment. This includes, for instance, the KSFO tile and the c172p. It's apparent that one, among many advantages of that approach is, that the confusing redundancy between the "default KSFO" and the "scenery KSFO", as it currently exists, will go. While the planes are the primary concern of the splitting and will bring a relief of a tremendous 4.5 Gigabytes to every user of FGDATA and rectify a lot of redundancies and confusion, other things might also be considered, say, ./Traffic (just a lucky guess). Practically everything which is orthogonal to the core and without which FG (assuming a plane and a tile) can properly run, should migrate. regards, ManDay ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
