Cloning fgdata with GIT submodules

[IAHM-COL]

IMPORTAT INFORMATION

The FGDATA has succesfully been transferred to the NEXT GENERATION FGDATA
Now also available (NOT IN TEST MODE) with Submodules

The location of FGMEMBERS remains unchanged at: https://github.com/FGMEMBERS
The Fork of the Official FGDATA can now be obtained at: https://sourceforge.net/p/fgdata/submod ... next/tree/

Read the Notification here:

viewtopic.php?f=28&t=25314&start=45#p234592

___________________________

For those following the FGDATA test Aircrafts as submodule:
FGDATA has been updated to follow all new changes in SVN until R328 (FEB25_2015).
New submodules included now that add several aircraft from Helijah's Hanger that are not included in the SVN repository, plus
A few aircraft from Omega Hangar that are GPLed
and Some new aircraft from JWocky Hangar, plus the JPack that includes his systems
and finally, a new version of the Osprey currently being worked by PH-ONOX and its pack ExtensionPack

Remember
If you are using this test FGDATA for purposes of testing feasibility of FGDATA systems:

To update already initialized aircraft

Code: Select all

$git pull
$git submodule update


To add a new submodule

Code: Select all

$ git pull #required to do here if you are attempting to add a newly added submodule
$ git submodule init Aircraft/JPack #this is an example
$ git submodule init Aircraft/Condor-Jsb #this is an example - dependency: it requires Aircraft/JPack
$ git submdoule update #updates all initialized submodules, previous and new


[IAHM-COL]

For those following the FGDATA test Aircrafts as submodule:


FGDATA has been updated to follow all new changes in SVN until R377 (MAR07_2015).

New Submodules added



We have new aircraft available for FGDATA in submodules. Mark Kraus, the creator of the unbelievable B707, has agreed allowing us to copy his previous aircraft in the FGMEMBERs area, and add a GPL2 notice to these aircraft. Now FGDATA has the following submodules allowing the test and enjoyment of other creations of his genious. Note: He disclaims that some aircraft may not longer work as he originally intended, because of changes in Fligthgear.

Some of his Aircrafts are actually not airplanes: Motorcycles such as the BMW and the Susuki, and a very curious Horse Model as Well... Enjoy!

• Aircraft/Horse
• Aircraft/DO-J-II
• Aircraft/Common-Spruce-CS1
• Aircraft/BMW-S-RR
• Aircraft/Kawa-ZX10R
• Aircraft/LCR
• Aircraft/Suzuki-GXS-R

From the JWOCKY USA TOUR READY productions, we also have new versions for

• Aircraft/Condor-Jsb
• Aircraft/Lancaster-Jsb
• Aircraft/FlyingFortress-Jsb
• Aircraft/VIP (Contains VIP versions of B747-8 and ERJ195 -Lineage 1000)
• Aircraft/JPack

Notification The aircrafts added as submodules above ARE NOT PRESENT in the official FG ADDON Subversion repository!

Important information

Currently D. Torsten is working hard to get us a new FGDATA git repository stripped from Aircrafts. That repository is the base FGDATA for us to effectively fork and add the submodules. Sitting the Aircrafts-as-submodules FGDATA fork downstream official Aircraft-less Fligthgear Official Repository will allow to fetch any changes done to the FGDATA repo, therefore maintaining our FGDATA in sync with all latest changes.

Stay tuned

Best,
IHCOL

[LesterBoffo]

Knowing which Aircraft had been recently updated?

The easiest way to know whether you have a submodule of an aircraft that has recently been updated is to look at those submodules that had been affected by the latests commit:

https://github.com/FGDATA/fgdata/tree/master/Aircraft

Here you can see which aircraft are affected/updated with changes until the SVN revision 295.

Best,
IHCOL

Noticed that this linked github listing is missing the AVRO IV triplane and the Eastbourne Monoplane.. both of mine from the main download page?

[IAHM-COL]

@Lester
Thanks for the report.

I find them no-missing
They are as

Aircraft/eastbourne_mono @ 0ebc625
and
Aircraft/ AVRO-IV-Triplane @ 6060fce

And can also be found and downloaded individually here:
https://github.com/FGMEMBERS/eastbourne_mono/
https://github.com/FGMEMBERS/AVRO-IV-Triplane/

I do know you have several other really amazing Aircraft that I'd love to incorporate to the FGDATA github lists, like the Vicker Nene, the Hampden, some motorcycles and others.

I will be very happy to get your authorization to list some of these cool crafts, with their particular names and maybe their dropboxes. Keep in mind that I currently only am uploading Aircraft that complies 100% with Flightgear license. That is, I am leaving outside Aircraft under creative commons or other licenses.

Best
IHCOL

[LesterBoffo]

Honestly? from your page link I copied..

either they are or they aren't, my search showed neither one was there and it was from your direct link...

Secondly, concerning some of the aircraft I have on Mediafire The makers of those planes expressed in their Readme's that they didn't want their material to become commercial use, they were kind enough to respond to my requests, and to allow under Creative Commons NC SA.

[IAHM-COL]

Yes. Oh I see!
The list is not quite alphabetical! ::oopss::

the capital letters are listed above:

See here:



Way above on _Capital_A _Capital_V_ listings a bit above your screenshot
and

Here


Way at the end, where non-capitals start to be listed.

(weird, eh?)

Secondly,
I know some of the cool aircraft you have are CC. I am just not sure if, in addition to the AVRO and the eastbourne, there are other GPLs in your listings.
But I do understand the limitations and intentions of the authors, and I am not requesting a "switching of license" on the aircrafts not GPL already.

Best,
IHCOL

but let me investigate. I'll try to figure it out.

[IAHM-COL]

IMPORTANT INFORMATION


For all flightgears that had followed, tested and used the FGDATA with submodules TEST repository.

GREAT NEWS!

Thanks to the efforts and coordination of several Fligthgear core developers, particularly Torsten Dreyer, Fligthgear now has migrated FGDATA git repository to a newly created git repository that is completely stripped of the aircraft collection.


After this repository has been made available, I had succesfully Forked FGDATA and re-assembled a modular FGDATA that contains All of the Aircrafts previously in FGDATA + several more now available also in FGADDON + several more Flightgear GPL aircrafts available and developed in multiple other Hangars (Prestes, Omega, Helijah, JWOCKY, and Lake of constance) -- more to come!

I proudly present: THE FGDATA NEXT GENERATION WITH AIRCRAFTS AS SUBMODULES

https://sourceforge.net/p/fgdata/submod ... next/tree/

For constrains of repository size (currently 1.3GB), and to migrate the FGDATA along with the official repository, the FGDATA NEXT with submodules will not be hosted in GITHUB (sad face) but on Sourceforge.
The methods for using the repository, thou, don't change at all. And all Aircraft modules are still hosted and developed under GITHUB user friendly plattform, IN FGMEMBERS: https://github.com/FGMEMBERS

Using FGDATA NEXT with submodules to obtain the latest FGROOT directory with some or all aircraft as submodules

This is a brief instruction on how to get started. I will be preparing a more comprehensive WIKI page that includes multiple details, FAQs, and illustrations. But I am placing this info here for the ones Eager to get started!

Cloning the FGDATA NEXT GENERATION

You can clone it from the official FGDATA NEXT or the fork with submodules, likewise. But for simplicity here, I will begin with the assumption that FGDATA is cloned from the fork with submodules

Code: Select all

$git clone http://git.code.sf.net/p/fgdata/submodules fgdata


Initializing submodules:: Getting some or All aircraft

Inside the fgdata directory that is created while cloning

Example

Code: Select all

$git submodule init Aircraft/707
$git submodule init Aircraft/b190d
...
etc


Do this for every aircraft you wish to install!
(read the file .gitmodules or list the directory Aircraft to know what options do exist!)

OR

Code: Select all

$ git submodule init


Do this if you wish to install ALL submodules-Aircrafts

Installing the submodules::
After preparing your FGDATA, you can either install or update the aircrafts you have chosen (or all!)

Code: Select all

$ git submodule update


AND THAT's it. Locally you have generated exactly the flavor of FGDATA that you wished for!
(no need to keep additional paths in your disc to hold these aircraft, or point Flightgear to an aircraft folder, or location!)


ENJOY!
Best,
IHCOL

[F-JJTH]

Can you confirm me that I'm right with these assumptions:

If I want 1 aircraft with your GIT submodule I have to do

Code: Select all

git clone https://git.code.sf.net/p/fgdata/submodules fgdata
cd fgdata
git submodule init Aircraft/707

If I want 1 aircraft with SVN I have to do

Code: Select all

svn checkout svn checkout svn://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/707

If I want to remove 1 aircraft with your GIT submodule I have to do

Code: Select all

git deinit Aircraft/707

If I want to remove 1 aircraft with SVN I have to do
Just press the "delete" key of my keyboard when 707 is selected in my file manager (the same way i would delete a music or pic finally)



If I want all aircraft with your GIT submodule I have to do

Code: Select all

git clone https://git.code.sf.net/p/fgdata/submodules fgdata
cd fgdata
git submodule init

If I want all aircraft with SVN I have to do

Code: Select all

svn checkout svn://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft

If I want to update all aircraft with you GIT submodule I have to do

Code: Select all

git submodule update

If I want to update all aircraft with SVN I have to do

Code: Select all

svn update

If all of this is correct, can you explain why I would use your GIT submodule ?
At the end of the day I can achieve all what I need with SVN... I don't see why your GIT submodule is better finally.
The GIT submodule vs SVN looks like if I had to make the choice between "white color vs white color" to me.

I'm not sure you would spend your time and energy with your GIT submodule because it doesn't bring any 'amazing' feature compared to the SVN solution.

I suspect your GIT submodule is likely introducing a lot of confusion in the community :/
I heard some people saying "hmm I'm lost there is 2 Aircrafts repository now ?! where should I contribute ? where should I download latest version ?".
But if you are happy to create such confusion in the community, that's fine

Kind regards,
Clément

[Hooray]

I suspect your GIT submodule is likely introducing a lot of confusion in the community :/
I heard some people saying "hmm I'm lost there is 2 Aircrafts repository now ?! where should I contribute ? where should I download latest version ?".
But if you are happy to create such confusion in the community, that's fine

Please let's try to be fair here - things ended up being rushed quite a bit recently (touching a ton of critical infrastructure), and while IAHM-COL certainly managed to draw all the attention to himself as being "the new guy" begging to be bashed on the devel list by others, there are other contributors, including core developers, who are voicing concerns with not just the the recent fgdata migration, but also sg/fg being moved to SF.net now, e.g.: http://sourceforge.net/p/flightgear/mai ... /33570315/

I do agree however, that having a multiple repositories and approaches will only add to the confusion, especially or less tech-savvy users.
I would suggest that people get involved to help improve the docs/infrastructure or scripted solutions (think cmake superbuild) instead of debating things for weeks, which isn't helping anybody at all, and only likely to frustrate folks

[wlbragg]

IAHM-COL certainly has taken a beating in the mailing list for voicing his opinion and broadcasting an alternative, I support his efforts. Not to lessen the efforts of those who move to svn. I'm sure it has its own merits.

I just hope we are paying attention to history (and I mean the history of failure with svn), by not repeating it. Not to mention the aircraft history which I am completely in disagreement as to the importance of retaining it (as in I think it is imperative to retain it). Anyone that thinks otherwise and is willing to loose that data is not the hoarder I am.

I currently pulled both systems in their entirety so I can judge for myself which one I like best. I can say for sure if one has history and one doesn't I will be using the one that does.

HClément, it doesn't have to be confusing, just think of it as a mirror with "additional" aircraft.

[IAHM-COL]

Can you confirm me that I'm right with these assumptions:

If I want 1 aircraft with your GIT submodule I have to do

Code: Select all

git clone https://git.code.sf.net/p/fgdata/submodules fgdata
cd fgdata
git submodule init Aircraft/707

Code: Select all

$ git clone http://git.code.sf.net/p/fgdata/submodules fgdata
$ cd fgdata
$ git submodule init Aircraft/707
$ git submodule update


If I want 1 aircraft with SVN I have to do

Code: Select all

svn checkout svn checkout svn://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/707

The steps above do include cloning FGDATA as well. The SVN goes more like this

Code: Select all

$ git clone http://git.code.sf.net/p/flightgear/fgdata fgdata
$ mkdir FG-ADDON; cd FG-ADDON
$ svn checkout svn://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/707


If I want to remove 1 aircraft with your GIT submodule I have to do

Code: Select all

git deinit Aircraft/707

If I want to remove 1 aircraft with your GIT submodule I have to do

Code: Select all

$ cd fgdata #The commands are performed in the repo root
$ git submodule deinit Aircraft/707
$ git submodule update


If I want to remove 1 aircraft with SVN I have to do
Just press the "delete" key of my keyboard when 707 is selected in my file manager (the same way i would delete a music or pic finally)

Yes, only if you are downloading 1 single aircraft, or are fetching the SVN FGADDON 1 aircraft at a time!. Keep in mind you are a commiter in the central repo, and caution needs to be exercised here!

Particularly, if you download the complete SVN repository

Code: Select all

svn checkout svn://svn.code.sf.net/p/flightgear/fgaddon/trunk flightgear-fgaddon


DO NOT ATTEMPT DELETING AIRCRAFTS INDIVIDUALLY AS YOU WOULD WITH A REGULAR PIC OR MUSIC FILE.

Doing so will only corrupt your repo, and

Code: Select all

$ svn up


May either get you the plane back, or fatally fail.

Furthermore, if you do remove the Aircraft 707 folder from a complete repository, and you have commit access, you can accidentally, or intentionally, succeed in removing such aircraft to everyone else!
I urge you to avoid deleting an aircraft from the SVN repository mostly, at all cost.

If you just cloned one directory appart, as an SVN repo, go ahead and delete, since you are just actually removing the whole local copy of the repo.

In the git with submodules strategy you can initialize or deinitialize as many aircraft as you want, without needing to remove directories within a repository

If I want all aircraft with your GIT submodule I have to do

Code: Select all

git clone https://git.code.sf.net/p/fgdata/submodules fgdata
cd fgdata
git submodule init

If I want all aircraft with your GIT submodule I have to do

Code: Select all

$ git clone http://git.code.sf.net/p/fgdata/submodules fgdata
$ cd fgdata
$ git submodule init
$ git submodule update


Also there is a keystrokes-saving alternative

Code: Select all

$ git clone --recursive http://git.code.sf.net/p/fgdata/submodules fgdata


If I want all aircraft with SVN I have to do

Code: Select all

svn checkout svn://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft

Remember the steps above imply cloning of FGDATA as well

Code: Select all

$ git clone http://git.code.sf.net/p/flightgear/fgdata fgdata
$ mkdir FG-ADDON; cd FG-ADDON
$ svn checkout svn://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft


If I want to update all aircraft with you GIT submodule I have to do

Code: Select all

git submodule update

Code: Select all

$ cd fgdata #the commands need to be performed in the repository root folder
$ git pull #you need to first update the FGDATA repository
$ git submodule update


This effectively updates ALL aircraft initialized. NOT ALL AIRCRAFT. If you have lets say 20 aircraft initialized, you only update 20 aircraft. That is, you update those aircraft that you care to install in the first place. Greater control of what you need-and you have.

If I want to update all aircraft with SVN I have to do

Code: Select all

svn update

That is correct, if basically you obtained the complete 20GB aircraft collection. If on the contrary you just have lets say 20 directories having 20 aircraft that you care about, the recommended update for all of them, will look (in a linux box) something like

Code: Select all

$ cd FG-ADDON #here you have 20 aircraft all cloned individually - a fair comparison to initializing 20 submodules
$ for file in ./*
> do
> cd $file
> svn up
> cd ..
done
$


If all of this is correct, can you explain why I would use your GIT submodule ?
At the end of the day I can achieve all what I need with SVN... I don't see why your GIT submodule is better finally.
The GIT submodule vs SVN looks like if I had to make the choice between "white color vs white color" to me.

It is a significantly harder problem that a problem of chosing two shades of white. There are several advantages in a decentralized way of developing aircraft vs a centralized way. There are advantages on having aircraft being their individual repos, and gaining lots of control on their development too.

One of the nice features of the submodules strategy for the fligthgear aircraft is the possibility to point to a development status of every aircraft (a given commit in the commit history) as the "current stable" version, and let the development progress unrestricted. When a new status is reached then the fgdata is updated to point to the newer commit, therefore gaining lots on stability of the aircraft. With SVN alternative, you will only have the option of staying on top of the developing wave.

Lets imaging aircraft/p51d
Lets say such aircraft is being actively developed. And commits occur in a daily basis with not only fixes (*) but also experimental features that come and go (o)
Lets say the aircraft is stable at A, and throught the weeks it actually improves largely to B
Lets say FGDATA points to commit A

Then,

A > * > * > o > o > o > o > * > o > o > * > * > o > o > B

FGDATA submodules has always pointed to A, regardless of the commit status of the development branch of p51D

Last step

Update FGDATA to point to B

That way you can see how the fgdata version actually was masked of all instabilities of the development branch.

Also, within a git rooted system, you can allow multiple authors to collaborate simultaneously in a single aircraft, and test multiple different alternatives, by having each of them having a branch of their own. Then bring the work together. Its all about enpowering users to collaborate actively in development. Not limiting to a trust-ring of who can effectively write or not a given central repository.

I'm not sure you would spend your time and energy with your GIT submodule because it doesn't bring any 'amazing' feature compared to the SVN solution.

Roger that. But I am sure I am happy I spent a few hours of my time and a lot of keystroking energy setting a couple of cronjobs to sync FGDATA NEXT and the FG-ADDON SVN with this submodular alternative

I suspect your GIT submodule is likely introducing a lot of confusion in the community :/
I heard some people saying "hmm I'm lost there is 2 Aircrafts repository now ?! where should I contribute ? where should I download latest version ?".
But if you are happy to create such confusion in the community, that's fine

Kind regards,
Clément

I'm happy with having an alternative way to fetch FGDATA with the aircrafts I want installed. To have a very flexible way to get aircraft installed, de-installed and updated. To have an alternative set of aircraft repositories where everyone can be welcome to participate without endangering the integrity of the whole project, or being given write access to it. Where merging, branching and rebasing are possibilities.
I am also happy to help any user that is confuse.

Kind Regards,
Israel

[IAHM-COL]

HClément, it doesn't have to be confusing, just think of it as a mirror with "additional" aircraft.

Not only that.
I had asked more than a few times
to
1) reconstruct the FG-ADDON with aircraft history
and
2) to permit the FGMEMBERs aircraft to be rebased on top of the FGADDON before the latter being merged on the former.

If they have identical commit histories, this way they could be really mirrors of each other, and for the ultimate user it just a matter of choice between mirrors.

In the current set up, we have divergent aircraft development branches. Since I made a cronjob that effectively updates all changs in SVN to the FGMEMBERs area, all changes in the FGADDON occur also in FGMEMBERs with 1 week delay or less. Changes occurring in FGMEMBERs are sole and exclusive code changes of that area.

[IAHM-COL]

Please let's try to be fair here - things ended up being rushed quite a bit recently (touching a ton of critical infrastructure),

I still don't quite get why we liberally ditch commit history (Aircraft, AI, Models, and Scenery), but probably more importantly, why we had discarded all release branches from /release2.0 ahead.
This is now not of great repercusions, but as we are facing a removal of all material hosted in gitorious, it effectively means we are currently down the road of loosing those stable status.

[Hooray]

"change" in the FG eco system happens very rarely, there's a ton of inertia involved usually - however, when it happens, it's usually very drastic and introduces a ton of regressions that people have to live with - given all the usual inertia, that's simply the compromise that needs to be made

[wlbragg]

it's usually very drastic and introduces a ton of regressions that people have to live with
......
that's simply the compromise that needs to be made

Where's the "need" to eliminate the history?
I'm dumbfounded over the willingness to discard that kind of historical data.

If they have identical commit histories, this way they could be really mirrors of each other, and for the ultimate user it just a matter of choice between mirrors.

Sounds like a great plan to me.

It won't cause anyone but Israel any extra work.
It will give us a completely separate backup system.
It will give developers a choice to use the system they prefer.
It will help keep the "open" in "open source", it is already accepting off additional aircraft that might otherwise be necessary to track individually..

Where's the downside?

But no worries, I've retained my own personal local copy with all the history and thanks to the efforts of Israel, there is public source available (for now at least).