FGDATA next with submodules
Posted: Sat Sep 12, 2015 8:47 pm
Hi ALL
The Modular FGDATA for test purposes is completely uploaded now.
I call this the "TEST 2" because is not quite a fork yet. It is more an snapshot of the fgdata on version 3.5.0 as it stood on Feb*05*2015
See more details above of my request for a conversation on the future of storing aircraft in FG, but I animously invite everyone to test ride this method using the test FGDATA provided: Here are the basic guidelines
1. Required:
A git software, ideally version 1.8 or more for having all functionality with submodules. Examples below are for the command line (or the git-bash) that comes with your git software. Using GUI versions all this must be possible, but I had not tested it
2. Initial FGDATA cloning.
This is done equally as the current FGDATA git is cloned. But there is a twist.
2. Installing new Aircraft
As I mentioned, this FGDATA is modular, and the cloning did not bring all aircraft. To bring an aircraft, its submodule needs to be initialized. Then the initialized modules updated.
Such code will initialize your repo to also have the amazing lake of constanze 707. then by updating it, it brings the aircraft to your local repo of FGDATA
You can initialize as many aircraft as wanted. No limit. All Initialized submodu2. Initial FGDATA cloning. les are updated with the single update command simmultaneously!
(one can make a bash script to initialize multiple aircraft, or so)
3. NAH! I want 469 additional aircraft to the less command approach.
Well again, there is a nice feature: submodule init without parameters will initialize all submodules in a shot
4. Uninstalling modules
For the end user, after you initialize an Aircraft, the GIT proper way of ditching it out is:
(Why would someone do that goes beyond my understanding but oh well... this is for test purposes rite?!)
Having an option of deinstalling submodules is a cool advantage to reduce the size of one own's fgdata repo that is not that easy in the monolithic current approach.
Also
Will actually very efficiently get you back to the basic package!
5. Forewarning
This repository is currently just a test frame for a possible implementation of modularity in the FGDATA git.
DO NOT USE for a main installation, and reffer to the official channel in https://gitorious.org/fg/fgdata/source/ ... 32dcff9727: for reliability purposes!!
The most important thing to note, is that the test fgdata is currently just an snapshot of version 3.5.0 an Feb*05*2015, not a real fork. So that FGDATA lacks all branches, and previous history of the official channel. And in addition, remote cannot be properly redirected to be able to fetch from the official one (just yet!)
The only way to use the FGDATA provided in this test with an actual flightgear installation is to
1. change the file version to the proper string, example from 3.5.0 to 3.3.0
2. point your fglauncher to the FGDATA obtained here (with fgrun, fgx, or the command line --fg-root option)
3. I tested this FGDATA with FG 3.2, 3.3 and 3.5, and it workd. I tested it with FG 2.12 and it did not, logging in creating nav data infinetely
6. This method of fetching FGDATA
Maintains a reduced size of the base package in the repository.
Submodules initialized do not effectively increase the size of a repo, with the exception of a few lines of code in .gitmodule and .git/config lines
So, it accomplishes the main goal of reducing FGDATA size, but maintains aircraft development in an git state
Furthermore, Git submodules can point to ANY repo, so these could be even pointing to aircraft repositories in development by any FG member, in any place, as much as they agree with conform with GPL.
7. Give it a test ride to the test
There is lots of red-tags concerns online about modules, but I think they are actually quite fit for the FGDATA part of fligthgear project. And a very powerful mode we could actually get to manage and develop our aircraft.
Every Aircraft in a submodule is effectively a git somewhere else, and that somewhere else can be developed on its own.
The FGDATA is actually just having a pointer to a certain commit on the development tree of such aircraft. This can be move to a different commit later, but it has the advantage that if a given plane is being developed, assuming no-one destroys the "history" of that plane, the status of such plane in FGDATA is the same until the commit pointed to is updated!.
A major suggestion is to never "develop" a submodule inside the main tree (FGDATA). Instead having an independent "development clone". So FGDATA does not get "mess up" with changes in its tree. Things may need to be figured out in more detail, but in general terms, I think, we can practice and experience with this test frame I created.
Furthermore, I am currently trying to rescue the "git history" of each individualized aircraft; figuring out the filter-branch option Anders has kindly pointed me too ....
Best to all
IHCOL
The Modular FGDATA for test purposes is completely uploaded now.
I call this the "TEST 2" because is not quite a fork yet. It is more an snapshot of the fgdata on version 3.5.0 as it stood on Feb*05*2015
See more details above of my request for a conversation on the future of storing aircraft in FG, but I animously invite everyone to test ride this method using the test FGDATA provided: Here are the basic guidelines
1. Required:
A git software, ideally version 1.8 or more for having all functionality with submodules. Examples below are for the command line (or the git-bash) that comes with your git software. Using GUI versions all this must be possible, but I had not tested it
2. Initial FGDATA cloning.
This is done equally as the current FGDATA git is cloned. But there is a twist.
- Current mainstream FGDATA: Its a huge repository that will bring all together a collection of about 485 aircraft. It brings down the complete suit and may take a significant time. Depending on your connection speed of course
- This Testing FGDATA; Its a modular repository. Cloning brings down ONLY what is known as the "BASE PACKAGE". It includes all folders and directories complete, as they stood on the snapshot taken for the example. BUT, in the Aircraft folder, it only includes 21 base folders, which includes the few initial aircraft of every "base packaged" Flightgear. The C172p, the F14, The 777, the B1900d, the UFO, are among this download aircraft. Bringing this base package creates a functionally complete flightgear, without the burning on downloading 469 additional aircraft in the first shot. It significantly reduces the "downloading time"
Code: Select all
$ git clone http://git.code.sf.net/p/fgdata/submodules fgdata-submodules
2. Installing new Aircraft
As I mentioned, this FGDATA is modular, and the cloning did not bring all aircraft. To bring an aircraft, its submodule needs to be initialized. Then the initialized modules updated.
Code: Select all
$ git submodule init Aircraft/707
$ git submodule update
Such code will initialize your repo to also have the amazing lake of constanze 707. then by updating it, it brings the aircraft to your local repo of FGDATA
You can initialize as many aircraft as wanted. No limit. All Initialized submodu2. Initial FGDATA cloning. les are updated with the single update command simmultaneously!
(one can make a bash script to initialize multiple aircraft, or so)
3. NAH! I want 469 additional aircraft to the less command approach.
Well again, there is a nice feature: submodule init without parameters will initialize all submodules in a shot
Code: Select all
$ git submodule init
$ git submodule update
or
$git submodule update --init
for an abbreviated form that initializes and updates the whole package
4. Uninstalling modules
For the end user, after you initialize an Aircraft, the GIT proper way of ditching it out is:
Code: Select all
$ git submodule deinit Aircraft/707
$git submodule update
(Why would someone do that goes beyond my understanding but oh well... this is for test purposes rite?!)
Having an option of deinstalling submodules is a cool advantage to reduce the size of one own's fgdata repo that is not that easy in the monolithic current approach.
Also
Code: Select all
$ git submodule deinit . #there is a point at the end there!
$git submodule update
Will actually very efficiently get you back to the basic package!
5. Forewarning
This repository is currently just a test frame for a possible implementation of modularity in the FGDATA git.
DO NOT USE for a main installation, and reffer to the official channel in https://gitorious.org/fg/fgdata/source/ ... 32dcff9727: for reliability purposes!!
The most important thing to note, is that the test fgdata is currently just an snapshot of version 3.5.0 an Feb*05*2015, not a real fork. So that FGDATA lacks all branches, and previous history of the official channel. And in addition, remote cannot be properly redirected to be able to fetch from the official one (just yet!)
The only way to use the FGDATA provided in this test with an actual flightgear installation is to
1. change the file version to the proper string, example from 3.5.0 to 3.3.0
2. point your fglauncher to the FGDATA obtained here (with fgrun, fgx, or the command line --fg-root option)
3. I tested this FGDATA with FG 3.2, 3.3 and 3.5, and it workd. I tested it with FG 2.12 and it did not, logging in creating nav data infinetely
6. This method of fetching FGDATA
Maintains a reduced size of the base package in the repository.
Submodules initialized do not effectively increase the size of a repo, with the exception of a few lines of code in .gitmodule and .git/config lines
So, it accomplishes the main goal of reducing FGDATA size, but maintains aircraft development in an git state
Furthermore, Git submodules can point to ANY repo, so these could be even pointing to aircraft repositories in development by any FG member, in any place, as much as they agree with conform with GPL.
7. Give it a test ride to the test
There is lots of red-tags concerns online about modules, but I think they are actually quite fit for the FGDATA part of fligthgear project. And a very powerful mode we could actually get to manage and develop our aircraft.
Every Aircraft in a submodule is effectively a git somewhere else, and that somewhere else can be developed on its own.
The FGDATA is actually just having a pointer to a certain commit on the development tree of such aircraft. This can be move to a different commit later, but it has the advantage that if a given plane is being developed, assuming no-one destroys the "history" of that plane, the status of such plane in FGDATA is the same until the commit pointed to is updated!.
A major suggestion is to never "develop" a submodule inside the main tree (FGDATA). Instead having an independent "development clone". So FGDATA does not get "mess up" with changes in its tree. Things may need to be figured out in more detail, but in general terms, I think, we can practice and experience with this test frame I created.
Furthermore, I am currently trying to rescue the "git history" of each individualized aircraft; figuring out the filter-branch option Anders has kindly pointed me too ....
Best to all
IHCOL
