F-JJTH wrote in Mon Mar 09, 2015 10:17 am: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 >
BFGDATA submodules has always pointed to A, regardless of the commit status of the development branch of p51D
Last step
Update FGDATA to point to BThat 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
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall