Re: [Flightgear-devel] FGData New Structure
Dear everyone,
a day late and I must admit the first version of the script really
wasn't what it was supposed to be, but here is the final version now.
Verified and tested on a small reproduction of FGData, example repo has
been uploaded[1].
The instructions have changed, no more tmpfs is required. Just browse
into your FGDATA, make sure the working dir is clean, and run the script
(which necessarily lies outside of the FGDATA dir).
There is one tiny problem which I was not entirely able to solve, that
is that not all tags appear to be sucessfully transfered. I must insist
though, that this is a negligible issue and given the project at hand,
clearly acceptable. In the worst case we will have to reset the few tags
on FGDATA were required.
In order to run the script on the example repo instead of the real
fgdata to check for yourself, you will have to change the settings
ac_dir and canonical as indicated in the first lines of the script to
the commented-out versions.
[1] http://ompldr.org/vYWZydg
#!/bin/bash
iodir=/tmp/fgsplit
final_ac=../split_airplanes_result/
final_fg=../split_fgdata_result/
ac_dir=Aircraft
canonical=origin/master
#canonical=master
#ac_dir=Aircrafts
#dornot2d=-d $iodir
bare=--bare
echo
Splitting FGDATA in 10 Seconds - Press Ctrl-C to cancel!
WARNINGS
Make _ABSOLUTELY SURE_ that you are in the right repository
Running this script in a wrong repository will have unpredictable
results!
Make sure to have $iodir mounted as tmpfs with all the storage
that you can spare, at least the size of the tree, which is 6GB
All data in the following directories will be purged, if they
already exist:
$final_ac $final_fg
NOTE
_NO_ irreversible changes will be made to your local repository
The resulting 'split' repositories after the spit can be found in
$final_ac
and
$final_fg
If satisfied with the results you can then delete this very repo
Which will, of course, seal the deal and make it irreversible
sleep 10;
if ! git status ; then
echo ERROR - Please navigate into the root of the FGDATA repository
exit
fi
echo Removing $final_ac $final_fg and $iodir
rm -RI $final_ac $final_fg $iodir
mkdir -p $final_ac $final_fg
origin=$(pwd)
sleep 1
echo Bringing up to date
git pull
echo Going onto canonical master
git checkout $canonical
echo Creating branches for all aircrafts
for acf in ./$ac_dir/* ; do
ac=${acf#./$ac_dir/}
acbn=SPLIT-$ac
if [[ $ac == Generic || $ac == Instruments || $ac ==
Instruments-3d ]] ; then
echo Skipping $ac
continue ;
fi
echo Going onto canonical master
git checkout $canonical
echo Branching for $ac ;
git branch $acbn
echo Switching to new branch;
git checkout $acbn
echo Isolating, please wait;
git filter-branch -f $dornot2d --subdirectory-filter $ac_dir/$ac
(
echo Extracting into new repository
cd $final_ac
mkdir $ac
cd $ac
git init $bare
git fetch $origin $acbn
git branch master FETCH_HEAD
)
done
echo Going onto canonical master
git checkout $canonical
echo Branching for reduced FGDATA
git branch SPLIT-CORE
git checkout SPLIT-CORE
echo Isolating, please wait
git filter-branch -f $dornot2d --index-filter git rm --cached --ignore-unmatch
$ac_dir/*
cd $final_fg
echo Extracting into new repository
git init $bare
git fetch $origin SPLIT-CORE
git branch master FETCH_HEAD
echo Done. Please verify the results.
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData New Structure
Le 17/09/2011 20:26, Vivian Meazza a écrit : Cedric wrote 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. I think this is an offer we can't refuse. I think these proposals are as good as any, and are in line with what Tim Moore was doing. Perhaps we should go for a phased approach. In the fist phase, we could split out the aircraft, then further restructuring could form subsequent phases. Cedric might like to start work on his script as soon as possible. Vivian Yup ! -- BlackBerryreg; 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 -- BlackBerryreg; 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
Re: [Flightgear-devel] FGData New Structure
Hello everybody, I'll keep this message as short as I can for some reason: We have built a script which will extract all Aircraft/* apart from Generic, Instruments and Instruments-3d into separate, cleaned up repositories and also extract the clean fgdata. The script is attached. Now we need to ask you the following: The problem we have is that this script cannot be ran on Gitorious directly. For one, because we don't have the required shell access there and second, because the operations required to perform the split put a tremendous load on I/O and CPU. With the size of FGDATA it would be impossible to perform the operation on the Gitorious servers. We need someone to run this script locally and then clone the result(s) onto gitorious. For that you require - Linux and root access (in order to mount a tmpfs) - A good amount of RAM (at least 6 Gigabytes) - A decent CPU - Patience - A stable PC - and finally a stable internet connection to be able to clone the results into Gitorious - And possibly patience if the script fails to have me make the necessary adjustments. The script does not perform any irreversible operations and will certainly not cause any damage (it is very simple and linear, you might look at it yourself), however, I can of course make no guarantee for anything so you best don't run it on a repository which has pending commits to be pushed. If you are willing to do this (I cannot do this for I fall short of a stable inet connection), you must read the following. Some preps are in place: You need to mount /tmp/fgsplit as a tmpfs with at least 6 gigabytes ram. This is not strictly required but otherwise you would have to straing your HDD with an enourmous amount of IO. After you mounted that, navigate to your fgdata directory (as user, you only need root for mounting the tmpfs) and run the script from there. possibly press Ctrl-C on the first run to read the message that comes up. Make sure you run the script on a fully committed working copy. If everything succeeds as planned, which could take many hours, the results can be found one directory up (as described in the message) and your current fgdata will have a bunch of new branches which you can delete, which will return your repo to the old state. You may eventually delete your old (then untouched) fgdata and clone the results to gitorious. The script itsself uses just basic git commands to extract the various parts into the target directories and leaves master of your current FGDATA unaffected. any questions feel free to ask or join on IRC (I'be there arround 1800 GMT) The principle of the script has been tested on a small scale repository and it should therefore work. Failure is absolutly possible, if not likely, but the worst thing that may happen is that it doesnt start properly for one or another reason. best thing you can do is look at the script yourself and see what it does. I'd be glad if we could eventually get this done. Thank you, regards, ManDay -- BlackBerryreg; 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
Re: [Flightgear-devel] FGData New Structure
... And here is the script
#!/bin/bash
echo 'Splitting FGDATA in 10 Seconds - Press Ctrl-C to cancel!'
echo ' WARNING '
echo 'Make _ABSOLUTELY SURE_ that you are in the right repository'
echo 'Running this script in a wrong repository will have unpredictable'
echo 'results!'
echo ' NOTE '
echo '_NO_ irreversible changes will be made to your local repository'
echo 'The resulting split repositories after the spit can be found in'
echo ' ../split_fgdata_result/'
echo 'and'
echo ' ../split_airplanes_result/'
echo 'If satisfied with the results you can then delete this very repo'
echo 'Which will, of course, seal the deal and make it irreversible'
sleep 10;
if ! git status ; then
echo ERROR - Please navigate into the root of the FGDATA repository
exit
fi
final_ac=../split_airplanes_result/
final_fg=../split_fgdata_result/
mkdir $final_ac
mkdir $final_fg
origin=$(pwd)
sleep 1
echo Bringing up to date
git pull
echo Going onto canonical master
git checkout origin/master
echo Creating branches for all aircrafts, hang on
for acf in ./Aircraft/* ; do
ac=${acf#./Aircraft/}
if [[ $ac == Generic || $ac == Instruments || $ac ==
Instruments-3d ]] ; then
continue ;
fi
echo Going onto canonical master
#git checkout origin/master
echo Branching for $ac ;
acbn=SPLIT-$ac
git branch $acbn
echo Switching...;
git checkout $acbn
echo Isolating...;
git filter-branch --subdirectory-filter /Aircraft/$ac
(
echo Creating new (bare) repository for $ac...
cd $final_ac
mkdir $ac
cd $ac
git init --bare
echo Extracting...
git fetch $origin $acbn
git branch master FETCH_HEAD
)
done
echo Going onto canonical master
git checkout origin/master
echo Branching for reduced FGDATA
git branch SPLIT-CORE
echo Reducing...
git filter-branch --index-filter 'git rm --cached --ignore-unmatch /Aircraft/*'
(
cd $final_fg
echo Creating new (bare) repository for fgdata
git init --bare
echo Extracting...
git fetch $origin SPLIT-CORE
git branch master FETCH_HEAD
)
echo DONE
--
BlackBerryreg; 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
Re: [Flightgear-devel] FGData New Structure
I'm afraid I attached the wrong version, here is the correct one.
#!/bin/bash
iodir=/tmp/fgsplit
echo 'Splitting FGDATA in 10 Seconds - Press Ctrl-C to cancel!'
echo ' WARNING '
echo 'Make _ABSOLUTELY SURE_ that you are in the right repository'
echo 'Running this script in a wrong repository will have unpredictable'
echo 'results! FURTHERMORE make sure to have'
echo $iodir
echo 'mounted as tmpfs with all the storage that you can spare'
echo ' NOTE '
echo '_NO_ irreversible changes will be made to your local repository'
echo 'The resulting split repositories after the spit can be found in'
echo ' ../split_fgdata_result/'
echo 'and'
echo ' ../split_airplanes_result/'
echo 'If satisfied with the results you can then delete this very repo'
echo 'Which will, of course, seal the deal and make it irreversible'
sleep 10;
if ! git status ; then
echo ERROR - Please navigate into the root of the FGDATA repository
exit
fi
final_ac=../split_airplanes_result/
final_fg=../split_fgdata_result/
mkdir $final_ac
mkdir $final_fg
origin=$(pwd)
sleep 1
echo Bringing up to date
git pull
echo Going onto canonical master
git checkout origin/master
echo Creating branches for all aircrafts, hang on
for acf in ./Aircraft/* ; do
ac=${acf#./Aircraft/}
if [[ $ac == Generic || $ac == Instruments || $ac ==
Instruments-3d ]] ; then
continue ;
fi
echo Going onto canonical master
#git checkout origin/master
echo Branching for $ac ;
acbn=SPLIT-$ac
git branch $acbn
echo Switching...;
git checkout $acbn
echo Isolating...;
git filter-branch --subdirectory-filter /Aircraft/$ac
(
echo Creating new (bare) repository for $ac...
cd $final_ac
mkdir $ac
cd $ac
git init --bare
echo Extracting...
git fetch $origin $acbn
git branch master FETCH_HEAD
)
done
echo Going onto canonical master
git checkout origin/master
echo Branching for reduced FGDATA
git branch SPLIT-CORE
echo Reducing...
git filter-branch --index-filter 'git rm --cached --ignore-unmatch /Aircraft/*'
(
cd $final_fg
echo Creating new (bare) repository for fgdata
git init --bare
echo Extracting...
git fetch $origin SPLIT-CORE
git branch master FETCH_HEAD
)
echo DONE
--
BlackBerryreg; 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
Re: [Flightgear-devel] FGData New Structure
Hopefully the right version now. Had to add something.
#!/bin/bash
iodir=/tmp/fgsplit
echo 'Splitting FGDATA in 10 Seconds - Press Ctrl-C to cancel!'
echo ' WARNING '
echo 'Make _ABSOLUTELY SURE_ that you are in the right repository'
echo 'Running this script in a wrong repository will have unpredictable'
echo 'results! FURTHERMORE make sure to have'
echo $iodir
echo 'mounted as tmpfs with all the storage that you can spare'
echo ' NOTE '
echo '_NO_ irreversible changes will be made to your local repository'
echo 'The resulting split repositories after the spit can be found in'
echo ' ../split_fgdata_result/'
echo 'and'
echo ' ../split_airplanes_result/'
echo 'If satisfied with the results you can then delete this very repo'
echo 'Which will, of course, seal the deal and make it irreversible'
sleep 10;
if ! git status ; then
echo ERROR - Please navigate into the root of the FGDATA repository
exit
fi
final_ac=../split_airplanes_result/
final_fg=../split_fgdata_result/
mkdir $final_ac
mkdir $final_fg
origin=$(pwd)
sleep 1
echo Bringing up to date
git pull
echo Going onto canonical master
git checkout origin/master
echo Creating branches for all aircrafts, hang on
for acf in ./Aircraft/* ; do
ac=${acf#./Aircraft/}
if [[ $ac == Generic || $ac == Instruments || $ac ==
Instruments-3d ]] ; then
continue ;
fi
echo Going onto canonical master
#git checkout origin/master
echo Branching for $ac ;
acbn=SPLIT-$ac
git branch $acbn
echo Switching...;
git checkout $acbn
echo Isolating...;
git filter-branch -d $iodir --subdirectory-filter /Aircraft/$ac
(
echo Creating new (bare) repository for $ac...
cd $final_ac
mkdir $ac
cd $ac
git init --bare
echo Extracting...
git fetch $origin $acbn
git branch master FETCH_HEAD
)
done
echo Going onto canonical master
git checkout origin/master
echo Branching for reduced FGDATA
git branch SPLIT-CORE
echo Reducing...
git filter-branch -d $iodir --index-filter 'git rm --cached --ignore-unmatch
/Aircraft/*'
(
cd $final_fg
echo Creating new (bare) repository for fgdata
git init --bare
echo Extracting...
git fetch $origin SPLIT-CORE
git branch master FETCH_HEAD
)
echo DONE
--
BlackBerryreg; 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
Re: [Flightgear-devel] FGData New Structure
On Sun, 18 Sep 2011 23:07:48 +0200, Cedric wrote in message 20110918210742.GA11631@engine: We need someone to run this script locally and then clone the result(s) onto gitorious. For that you require - Linux and root access (in order to mount a tmpfs) ..some of your script echo statements are unquoted, some single quoted and some double quoted. Probably works ok on GNU/Linux, (I'm on the road with a wee ass eeepc looking for a new home for my gasifier and my FG igloo) but I dunno about the other platforms, maybe play it safe and use double quoted echo statements? - A good amount of RAM (at least 6 Gigabytes) - A decent CPU - Patience - A stable PC - and finally a stable internet connection to be able to clone the results into Gitorious -- BlackBerryreg; 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
Re: [Flightgear-devel] FGData New Structure
Right. I've been a bit sloppy when I wrote this yesterday. I'll rewrite it in a more proper and failsafe manner today. You might want to want to wait until then. On Mon, Sep 19, 2011 at 12:21:40AM +0200, Arnt Karlsen wrote: On Sun, 18 Sep 2011 23:07:48 +0200, Cedric wrote in message 20110918210742.GA11631@engine: We need someone to run this script locally and then clone the result(s) onto gitorious. For that you require - Linux and root access (in order to mount a tmpfs) ..some of your script echo statements are unquoted, some single quoted and some double quoted. Probably works ok on GNU/Linux, (I'm on the road with a wee ass eeepc looking for a new home for my gasifier and my FG igloo) but I dunno about the other platforms, maybe play it safe and use double quoted echo statements? - A good amount of RAM (at least 6 Gigabytes) - A decent CPU - Patience - A stable PC - and finally a stable internet connection to be able to clone the results into Gitorious -- BlackBerryreg; 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 -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FGData New Structure
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 -- BlackBerryreg; 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
Re: [Flightgear-devel] FGData New Structure
Cedric wrote 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. I think this is an offer we can't refuse. I think these proposals are as good as any, and are in line with what Tim Moore was doing. Perhaps we should go for a phased approach. In the fist phase, we could split out the aircraft, then further restructuring could form subsequent phases. Cedric might like to start work on his script as soon as possible. Vivian -- BlackBerryreg; 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
