De/FGAddon: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
No edit summary
Line 3: Line 3:
[[File:FGAddon logo.png|270px|right]]
[[File:FGAddon logo.png|270px|right]]


Der offizielle '''FGAddon'''-Flugzeughangar ist ein Repository zur Versionskontrolle, der auf [[FlightGear|FlightGears]] [https://sourceforge.net/projects/flightgear/ SourceForge Infrastruktur] gehostet ist und für die alltägliche Entwicklung der Flugzeuge von FlightGear verwendet wird.  FGAddon ist ein {{wikipedia|Apache Subversion|noicon=1|lang=de}} Version Control Repository. In FGAddon enthalten sind Flugzeuge, die nicht Teil des Basispaket sind (im Basispaket enthalten sind die [[Cessna 172P]] und das [[UFO]] - Diese werden im [http://sourceforge.net/p/flightgear/fgdata FGData] Repository gehostet), aber sie sind mit jeder stabilen Version für die [http://www.flightgear.org/download/ FlightGear Downloadseiten] (3.4.0, 3.6.0, etc.) markiert.
Der offizielle '''FGAddon'''-Flugzeughangar ist ein Repository zur Versionskontrolle, der auf [[FlightGear|FlightGears]] [https://sourceforge.net/projects/flightgear/ SourceForge Infrastruktur] gehostet ist und für die alltägliche Entwicklung der Flugzeuge von FlightGear verwendet wird.  FGAddon ist ein {{wikipedia|Apache Subversion|noicon=1|lang=de}} Version Control Repository. In FGAddon enthalten sind Flugzeuge, die nicht Teil des Basispaketes sind (im Basispaket enthalten sind die [[Cessna 172P]] und das [[UFO]] - Diese werden im [http://sourceforge.net/p/flightgear/fgdata FGData] Repository gehostet), aber sie sind mit jeder stabilen Version für die [http://www.flightgear.org/download/ FlightGear Downloadseiten] (3.4.0, 3.6.0, etc.) markiert.


Die Flugzeuge, die im FGAddon-Repository entwickelt werden,  sollten als instabil betrachtet werden.  Bei der Verwendung einer stabilen Version von FlightGear, ist es am besten, ein Flugzeug mit der passenden Versionsnummer von der [http://www.flightgear.org/download/ FlightGear-Downloadseite] herunterzuladen.  Allerdings sind die Flugzeuge in FGAddon seit FlightGear 3.4 mit jeder stabilen Version durch sog. "Tags" markiert, wodurch die Subversion-Werkzeuge ein praktisches Hilfsmittel sein können, um einzelne Flugzeuge oder den gesamten offiziellen Flugzeughangar von FlightGear mit ca. 500 Flugzeugen passend für die jeweilige stabile FlightGear-Version zu erhalten.  Bei Verwendung des (täglich erstellten) [[FlightGear build server|FlightGear-nightly builds]] oder einer [[Building FlightGear|selbst kompilierten FlightGear-Version]] aus den [http://sourceforge.net/p/flightgear/_list/git Git-Versionskontroll-Repositories] ermöglicht FGAddon, die Flugzeuge passend zu den neuesten FlightGear-Entwicklungen zu erhalten.
Die Flugzeuge, die im FGAddon-Repository entwickelt werden,  sollten als instabil betrachtet werden.  Bei der Verwendung einer stabilen Version von FlightGear, ist es am besten, ein Flugzeug mit der passenden Versionsnummer von der [http://www.flightgear.org/download/ FlightGear-Downloadseite] herunterzuladen.  Allerdings sind die Flugzeuge in FGAddon seit FlightGear 3.4 mit jeder stabilen Version durch sog. "Tags" markiert, wodurch die Subversion-Werkzeuge ein praktisches Hilfsmittel sein können, um einzelne Flugzeuge oder den gesamten offiziellen Flugzeughangar von FlightGear mit ca. 500 Flugzeugen passend für die jeweilige stabile FlightGear-Version zu erhalten.  Bei Verwendung des (täglich erstellten) [[FlightGear build server|FlightGear-Nightly-Builds]] oder einer [[Building FlightGear|selbst kompilierten FlightGear-Version]] aus den [http://sourceforge.net/p/flightgear/_list/git Git-Versionskontroll-Repositories] ermöglicht FGAddon, die Flugzeuge passend zu den neuesten FlightGear-Entwicklungen zu erhalten.


== Geschichte ==
== Geschichte ==
Das FlightGear-Projekt wurde am 8. April 1996 von David Murr ins Leben gerufen, der die Idee zu einem neuen Flugsimulator hatte, welcher vollständig von Freiwilligen entwickelt wird.<ref>David Murr (Apr 9, 1996).  FlightGear Antrag 1.0: [https://groups.google.com/forum/#!msg/rec.aviation.simulators/ny8HFBE5_T8/OdtIiGNGJc8J "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@"].  Veröffentlicht auf der rec.aviation.simulators Newsgroup.</ref><ref>David Murr (1996).  FlightGear Antrag 2.0: [http://www.flightgear.org/proposal-2.0 FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0].</ref><ref>David Murr (Oct 29, 1996).  FlightGear Antrag 3.0: [http://www.flightgear.org/proposal-3.0 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here"].  Publiziert auf der [http://ftp.igh.cnrs.fr/pub/flightgear/www/old-stuff/flight-gear.9610 flight-gear@infoplane.com Verteilerliste].</ref><ref>David Murr (Sep 11, 1998).  FlightGear Antrag 3.0.1: [http://www.flightgear.org/proposal-3.0.1 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here"].</ref>.  Ein Teil der ursprünglichen Ziele bestand darin,  2D- und 3D-Grafikroutinen für den Simulator zu entwickeln.  Aber da dies eine gewaltige Aufgabe war, kam sie Anfang 1997 zu einem unfertigen Stillstand, als der Hauptentwickler Eric Korpela sich auf die Fertigstellung seiner Doktorarbeit konzentrieren wollte.  Daher hat Curtis Olson am 16. Mai 1997 eine neue Entwicklung mit einem neuen Projekt auf der Basis der OpenGL-Bibliotheken begonnen, so dass ein funktioneller Flugsimulator in einer kurzen Zeitspanne zusammengefügt wurde.<ref>Curtis Olson (Sep 28, 2015).  [http://forum.flightgear.org/viewtopic.php?f=42&t=27558&p=259048#p259021 Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@].  Veröffentlicht im FlightGear-Forum.</ref>.  Die ersten Commits waren zum ursprünglichen [[FlightGear CVS|flightgear und simgear CVS Versionskontrolle Repositories]].
Das FlightGear-Projekt wurde am 8. April 1996 von David Murr ins Leben gerufen, der die Idee zu einem neuen Flugsimulator hatte, welcher vollständig von Freiwilligen entwickelt wird.<ref>David Murr (Apr 9, 1996).  FlightGear Antrag 1.0: [https://groups.google.com/forum/#!msg/rec.aviation.simulators/ny8HFBE5_T8/OdtIiGNGJc8J "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@"].  Veröffentlicht auf der rec.aviation.simulators Newsgroup.</ref><ref>David Murr (1996).  FlightGear Antrag 2.0: [http://www.flightgear.org/proposal-2.0 FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0].</ref><ref>David Murr (Oct 29, 1996).  FlightGear Antrag 3.0: [http://www.flightgear.org/proposal-3.0 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here"].  Publiziert auf der [http://ftp.igh.cnrs.fr/pub/flightgear/www/old-stuff/flight-gear.9610 flight-gear@infoplane.com Verteilerliste].</ref><ref>David Murr (Sep 11, 1998).  FlightGear Antrag 3.0.1: [http://www.flightgear.org/proposal-3.0.1 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here"].</ref>.  Ein Teil der ursprünglichen Ziele bestand darin,  2D- und 3D-Grafikroutinen für den Simulator zu entwickeln.  Aber da dies eine gewaltige Aufgabe war, kam sie Anfang 1997 zu einem unfertigen Stillstand, als der Hauptentwickler Eric Korpela sich auf die Fertigstellung seiner Doktorarbeit konzentrieren wollte.  Daher hat Curtis Olson am 16. Mai 1997 eine neue Entwicklung mit einem neuen Projekt auf der Basis der OpenGL-Bibliotheken begonnen, so dass ein funktioneller Flugsimulator in einer kurzen Zeitspanne zusammengefügt wurde.<ref>Curtis Olson (Sep 28, 2015).  [http://forum.flightgear.org/viewtopic.php?f=42&t=27558&p=259048#p259021 Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@].  Veröffentlicht im FlightGear-Forum.</ref>.  Die ersten Commits erfolgten zu den ursprünglichen [[FlightGear CVS|flightgear und simgear CVS Versionskontrolle Repositories]].


Durch das Wachstum des FlightGear-Projektes hat die Größe, Menge und Qualität der FlightGear Software-Assets ebenfalls zugenommen.  Diese Assets waren nicht organisiert und wurden in verschiedenen Teilen des Internets verstreut.  Daher wurde beschlossen, ein Großteil dieser FlightGear-Inhalte in einem neuen zentralen CVS-Repository zu sammeln und zu speichern, welches am 22. Oktober 2000 erstellt wurde und fgadata genannt wurde.  Um die rechtliche Umverteilung dieser Assets als Teil der FlightGear-Distribution zu ermöglichen, wurde eine exklusive GPLv2 Politik angenommen.
Durch das Wachstum des FlightGear-Projektes hat die Größe, Menge und Qualität der FlightGear Software-Assets ebenfalls zugenommen.  Diese Assets waren nicht organisiert und wurden in verschiedenen Teilen des Internets verstreut.  Daher wurde beschlossen, ein Großteil dieser FlightGear-Inhalte in einem neuen zentralen CVS-Repository zu sammeln und zu speichern, welches am 22. Oktober 2000 erstellt wurde und fgadata genannt wurde.  Um die rechtliche Umverteilung dieser Assets als Teil der FlightGear-Distribution zu ermöglichen, wurde eine exklusive GPLv2 Politik angenommen.
Line 15: Line 15:
Diese Ereignisse führten zu einer [[FlightGear CVS|Massenmigration aller CVS-Repositories in neue Git-Repositories]].  Aufgrund von Problemen mit der Bandbreite wurde beschlossen, die neuen Repositories auf der Open-Source-Infrastruktur von Gitorious zu hosten.
Diese Ereignisse führten zu einer [[FlightGear CVS|Massenmigration aller CVS-Repositories in neue Git-Repositories]].  Aufgrund von Problemen mit der Bandbreite wurde beschlossen, die neuen Repositories auf der Open-Source-Infrastruktur von Gitorious zu hosten.


Im Laufe der Zeit, während dem Wachstum des FlightGear-Projekts, hat gleichzeitig die Größe und der Umfang des fgdata-Repos explosiv zugenommen, so dass eine Spaltung unvermeidlich war.  Ein erster Spaltungsversuch wurde von Gijs de Rooy am 18. Oktober 2011 organisiert und angekündigt<ref>Cedric Sodhi (Oct 18, 2011) [http://thread.gmane.org/gmane.games.flightgear.devel/66846 <nowiki>[Flightgear-devel]</nowiki> FGData Split Completed - a.k.a Life after the Split] Veröffentlicht auf der flightgear-devel Mailinglist.</ref>.  Jedes Flugzeug wurde in ein eigenes Git-Repository gestellt und alle Flugzeuge zurück an fgdata mit einem Git-Submodul Verfahren gebunden.  Aber dieser Versuch scheiterte und wurde aufgegeben.  Ab diesem Datum bis zum Ende des Jahres 2014 wurden die Pläne der Teilung von fgdata auf der Mailinglist der FlightGear-Entwickler diskutiert und im [[FlightGear Git: splitting fgdata]] Wiki-Artikel zusammengefasst.  In der Planungsphase war das Repository als fgdata-old bekannt, das in FGData (auch bekannt als fgdata-new) und FGAddon (auch bekannt als flightgear-aircraft und fgaircraft) aufgeteilt wurde.  Nach einem halben Jahrzehnt der Planung wurde beschlossen, dass die beste Lösung für FlightGear-Flugzeugentwicklung ein einziges zentrales Subversion-Repository wäre.  Dies würde Gemeinschaftsentwicklung und Wartung der Flugzeuge erleichtern und zur gleichen Zeit Modularität, kleinere Downloads und kleinere lokale Repositories liefern.
Im Laufe der Zeit, während des Wachstums des FlightGear-Projekts, haben gleichzeitig die Größe und der Umfang des fgdata-Repos explosiv zugenommen, so dass eine Spaltung unvermeidlich war.  Ein erster Spaltungsversuch wurde von Gijs de Rooy am 18. Oktober 2011 organisiert und angekündigt<ref>Cedric Sodhi (Oct 18, 2011) [http://thread.gmane.org/gmane.games.flightgear.devel/66846 <nowiki>[Flightgear-devel]</nowiki> FGData Split Completed - a.k.a Life after the Split] Veröffentlicht auf der flightgear-devel Mailinglist.</ref>.  Jedes Flugzeug wurde in ein eigenes Git-Repository gestellt und alle Flugzeuge zurück an fgdata mit einem Git-Submodul Verfahren gebunden.  Aber dieser Versuch scheiterte und wurde aufgegeben.  Ab diesem Datum bis zum Ende des Jahres 2014 wurden die Pläne der Teilung von fgdata auf der Mailinglist der FlightGear-Entwickler diskutiert und im [[FlightGear Git: splitting fgdata]] Wiki-Artikel zusammengefasst.  In der Planungsphase war das Repository als fgdata-old bekannt, das in FGData (auch bekannt als fgdata-new) und FGAddon (auch bekannt als flightgear-aircraft und fgaircraft) aufgeteilt wurde.  Nach einem halben Jahrzehnt der Planung wurde beschlossen, dass die beste Lösung für FlightGear-Flugzeugentwicklung ein einziges zentrales Subversion-Repository wäre.  Dies würde Gemeinschaftsentwicklung und Wartung der Flugzeuge erleichtern und zur gleichen Zeit Modularität, kleinere Downloads und kleinere lokale Repositories liefern.


Ende 2014 kündigte Gitorious, der Anbieter der Open-Source-Infrastruktur für den FlightGear Quellcode und Daten-Repositories, an, seine Dienstleistungen im Mai 2015 stillzulegen, wegen der Übernahme durch GitLab.  Diese katalysierte die Spaltung von fgdata-old und einen Umzug zur Open-Source-Infrastruktur von SourceForge für das Hosting der VC-Repositories.  Andere Teile der FlightGear-Infrastruktur waren bereits von Sourceforge gehostet, so dass dies ein natürlicher Schritt war.  Um das Geschäft zu besiegeln, stimmte SourceForge schriftlich zu,  die riesige FlightGear Flugzeugsammlung zu hosten, deren Größe in Open-Source-Kreisen konkurrenzlos ist.  Heute ist das FGAddon SVN-Repository zusammen mit den meisten der FlightGear-Projekt-Infrastrukturen auf Sourceforge gehostet.
Ende 2014 kündigte Gitorious, der Anbieter der Open-Source-Infrastruktur für den FlightGear Quellcode und die Daten-Repositories an, seine Dienstleistungen im Mai 2015 still zulegen. Grund war die Übernahme durch GitLab.  Dies katalysierte die Spaltung von fgdata-old und einem Umzug zur Open-Source-Infrastruktur von SourceForge für das Hosting der VC-Repositories.  Andere Teile der FlightGear-Infrastruktur waren bereits von Sourceforge gehostet, so dass dies ein natürlicher Schritt war.  Um das Geschäft zu besiegeln, stimmte SourceForge schriftlich zu,  die riesige FlightGear Flugzeugsammlung zu hosten, deren Größe in Open-Source-Kreisen konkurrenzlos ist.  Heute ist das FGAddon SVN-Repository zusammen mit den meisten der FlightGear-Projekt-Infrastrukturen auf Sourceforge gehostet.


Im August 2015 wurde ein neues politisches Dokument über FlightGear verfasst, um die ungeschriebenen Normen des Projekts zu kodifizieren<ref>[http://www.flightgear.org/flightgear-policy-document FlightGear Policy Document and Roadmap], Entwurfsdokument.</ref>.  Mit diesem Dokument wurde die Lizenzpolitik für die FlightGear Flugzeuge von einer GPLv2-Verpflichtung, zu einer GPLv2+ oder GPL-kompatibel<ref>[http://www.gnu.org/licenses/license-list.de.html GNU-Lizenz Kompatibilitätsliste].</ref> Haltung aktualisiert.  Allerdings wird zur Bekämpfung der Komplikationen durch Lizenz-Proliferation und für die Integrität und das Wohl des FlightGear-Projekts dringend empfohlen, neue Inhalte unter der GPLv2+ zu lizenzieren.
Im August 2015 wurde ein neues politisches Dokument über FlightGear verfasst, um die ungeschriebenen Normen des Projekts zu kodifizieren<ref>[http://www.flightgear.org/flightgear-policy-document FlightGear Policy Document and Roadmap], Entwurfsdokument.</ref>.  Mit diesem Dokument wurde die Lizenzpolitik für die FlightGear Flugzeuge von einer GPLv2-Verpflichtung, zu einer GPLv2+ oder GPL-kompatibel<ref>[http://www.gnu.org/licenses/license-list.de.html GNU-Lizenz Kompatibilitätsliste].</ref> Haltung aktualisiert.  Allerdings wird zur Bekämpfung der Komplikationen durch Lizenz-Proliferation und für die Integrität und das Wohl des FlightGear-Projekts dringend empfohlen, neue Inhalte unter der GPLv2+ zu lizenzieren.
Line 23: Line 23:
== Flugzeuge bekommen ==
== Flugzeuge bekommen ==


{{tip|Solltest Du Interesse an Flugzeugen für stabile FlightGear-Versionen, und keine Kenntnis von Versionskontrolle haben,  so solltest Du die [[FlightGear_hangars|FlightGear Hangars]] besuchen, um Flugzeuge herunterzuladen.}}
{{tip|Solltest Du ausschließlich Interesse an Flugzeugen für stabile FlightGear-Versionen haben und keine Ahnung von Versionskontrolle haben,  dann solltest Du die [[FlightGear_hangars|FlightGear Hangars]] besuchen, um Flugzeuge herunterzuladen.}}
{{caution|Bei unterschiedlichen Versionen von FlightGear und den FGAddon-Flugzugen sind seltsame Fehler zu erwarten, und die Kombination mit Versionskonflikten nicht von der FlightGear-Community unterstützt wird.}}
{{caution|Bei unterschiedlichen Versionen von FlightGear den FGAddon-Flugzugen sind seltsame Fehler zu erwarten, da die Kombination von Flugzeugen und Software mit Versionskonflikten nicht von der FlightGear-Community unterstützt wird.}}


Mithilfe der Subversion-Werkzeuge (SVN-Tools) kann die Verwendung des FGAddon-Hangars eine einfache Methode sein für den Erwerb von Flugzeugen für eine bestimmte FlightGear-Version, direkt von der offiziellen Quelle. Bei der Verwendung des neuesten [[FlightGear Build Server|FlightGear Nightly Build]] oder einer [[Building FlightGear|selbst kompilierten Version von FlightGear]] sollten die neuesten Entwicklungsversionen der Flugzeuge verwendet werden, so dass die Versionen übereinstimmen.  Aus der Perspektive eines FlightGear-Benutzers wird im Folgenden beschrieben, wie man das offizielle Repository verwenden sollte, um Flugzeuge zu erhalten.
Mithilfe der Subversion-Werkzeuge (SVN-Tools) kann die Verwendung des FGAddon-Hangars eine einfache Methode sein um Flugzeuge für eine bestimmte FlightGear-Version direkt von der offiziellen Quelle zu erwerben. Bei der Verwendung des neuesten [[FlightGear Build Server|FlightGear Nightly Build]] oder einer [[Building FlightGear|selbst kompilierten Version von FlightGear]] sollten die neuesten Entwicklungsversionen der Flugzeuge verwendet werden, so dass die Versionen von Flugzeug und Software übereinstimmen.  Aus der Perspektive eines FlightGear-Benutzers wird im Folgenden beschrieben, wie man das offizielle Repository verwenden sollte, um die gewünschten Flugzeuge zu erhalten.


=== Vorbereitung ===
=== Vorbereitung ===


Um das FGAddon-Repository zu verwenden, müssen die Subversion-Werkzeuge installieren werden:
Um das FGAddon-Repository zu verwenden, müssen die Subversion-Werkzeuge installieren werden:
* '''MS Windows''': Installiere eine der [https://subversion.apache.org/packages.html#windows zahlreichen Subversion-Clients]. Zum Beispiel ist [https://sliksvn.com/download/ SlikSVN] eine der besten Versionen für die Kommandozeile und am Besten geeignetf für die Flugzeugentwicklung; [http://tortoisesvn.net/ TortoiseSVN] bietet durch Integration in den Windows Explorer eine benutzerfreundliche Bedienung.
* '''MS Windows''': Installiere eine der [https://subversion.apache.org/packages.html#windows zahlreichen Subversion-Clients]. Zum Beispiel ist [https://sliksvn.com/download/ SlikSVN] eine der besten Versionen für die Kommandozeile und am Besten geeignetf für die Flugzeugentwicklung; [http://tortoisesvn.net/ TortoiseSVN] bietet durch Integration in den Windows Explorer eine benutzerfreundliche Bedienung.
* '''Mac OS X''': Installiere das [https://subversion.apache.org/packages.html#osx offizielle Subversion-Client].
* '''Mac OS X''': Installiere das [https://subversion.apache.org/packages.html#osx offizielle Subversion-Client].
Line 85: Line 86:
=== Fliegen ===
=== Fliegen ===


Um die neuen heruntergeladenen Flugzeuge zu verwenden, lesen Sie bitter den Artikel [[De/Howto:Flugzeuge_Installieren|Howto: Flugzeuge Installieren]].  Sie können die Anleitung zum Download und Entpackung des Flugzeugs überspringen.
Um die neuen heruntergeladenen Flugzeuge zu verwenden, empfiehlt es sich den Artikel [[De/Howto:Flugzeuge_Installieren|Howto: Flugzeuge Installieren]] zu lesenDie Anleitung zum Download und zum Entpacken des Flugzeugs kann mit dem Wissen aus diesem Artikel getrost übersprungen werden.


=== Aktualisierung der Flugzeuge ===
=== Aktualisierung der Flugzeuge ===
Mit einer Checkout-Kopie der <code>/trunk</code>-Entwicklungsversion, kannst Du das Flugzeug auf den neuesten Stand aktualisieren, indem Du folgenden Befehl eingibst:
Mit einer Checkout-Kopie der <code>/trunk</code>-Entwicklungsversion, kannst Du das Flugzeug auf den neuesten Stand aktualisieren, indem Du folgenden Befehl eingibst:
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
Line 95: Line 97:
== Flugzeugentwicklung ==
== Flugzeugentwicklung ==


{{tip|Die FlightGear-Gemeinschaft fördert, dass die Flugzeugentwicklung direkt in FGAddon stattfindet.}}
{{tip|Die FlightGear-Gemeinschaft fördert die Flugzeugentwicklung direkt im FGAddon Repository. Das macht die Arbeit einheitlich und für alle einfacher.}}


=== Kontakt mit den ursprünglichen Flugzeug Autoren ===
=== Kontakt mit den ursprünglichen Flugzeug Autoren ===


Der erste Schritt für die Entwicklung und Erweiterung von Flugzeugen des offiziellen FlightGear-Hangar, oder auch von einem des [[Flightgear_hangars#Aircraft_hangars|privaten Hangars]], ist, den Kontakt mit den ursprünglichen Flugzeug-Autoren zu machen. Ihre Namen können in der <code>*-set.xml</code> Datei innerhalb des <code><authors></code> XML-Tag gefunden werden.  Oft werden ihre Kontakt-Email-Adressen in der README Datei oder in einer anderen Textdatei im Flugzeug Basisverzeichnis aufgelistet.  Wenn nicht, kann der Kontakt manchmal durch die [https://lists.sourceforge.net/lists/listinfo/flightgear-devel Mailinglist der FlightGear-Entwicklung] etabliert werden.  Kontakt mit den ursprünglichen Autoren ist wichtig, um herauszufinden, ob ein Flugzeug in aktiver Entwicklung ist und ob Sie als Teil des Entwicklungsteams eintreten können.
Der erste Schritt für die Entwicklung und Erweiterung von Flugzeugen des offiziellen FlightGear-Hangars, oder auch von einem der [[Flightgear_hangars#Aircraft_hangars|privaten Hangars]], ist der Kontakt mit den ursprünglichen Flugzeug-Autor. Deren Namen können in der <code>*-set.xml</code> Datei innerhalb des <code><authors></code> XML-Tags gefunden werden.  Oft werden ihre Kontakt-Email-Adressen in der README Datei oder in einer anderen Textdatei im Flugzeug Basisverzeichnis aufgelistet.  Ist das nicht der Fall, kann der Kontakt manchmal durch die [https://lists.sourceforge.net/lists/listinfo/flightgear-devel Mailinglist der FlightGear-Entwicklung] hergestellt werden.  Kontakt mit den ursprünglichen Autoren ist wichtig, um herauszufinden, ob ein Flugzeug in aktiver Entwicklung ist und ob Du Dich aktiv an der Entwicklung (vielleicht als Mitglied des Entwickler Teams) beteiligen kannst.  


=== SourceForge Konto ===
=== SourceForge Konto ===


Um auf der offiziellen Flugzeugsammlung zu arbeiten, sollte ein [https://sourceforge.net/user/registration/ SourceForge Konto] zum erst einrichten.  Dies wird entweder direkt Commit-Zugriff an den FGAddon Repository bieten, wenn Commit-Zugriff erteilt wurde, oder als Teil eines SourceForge Entwicklungsteam erlauben. Das Registrierungsverfahren ist blitzschnell und die Infrastrukturen und Leistungen für SourceForge Entwicklern werden in weniger als eine Minute greifbar sein.
Um an der offiziellen Flugzeugsammlung arbeiten zu können, sollte zunächst ein eigenes [https://sourceforge.net/user/registration/ SourceForge Konto] angelegt werden.  Dies ist kostenlos und ermöglicht den direkten Commit-Zugriff auf das FGAddon Repository. Entsprechende Rechte müssen zunächst durch das SourceForge Entwicklungsteam zur Verfügung gestellt werden. Das Registrierungsverfahren ist schnell und unkompliziert erledigt. So bekommt man bereits nach wenigen Minuten vollen Zugriff auf alle Leistungen der Plattform sowie auf die verschiedenen Repositories von FlightGear.  


=== Commit-Zugriff ===
=== Commit-Zugriff ===


Vor dem Erhalt von Commit-Zugriff sollte alle Anstrengungen unternehmen, um die ursprünglichen Autoren zu kontaktieren, um festzustellen, ob das Flugzeug aktiv entwickelt ist. Wenn nicht erfolgreich melden Sie für die Entwicklung Mailingliste an und frage dort nach Hilfe. Ansonsten fragen, ob jemand als Freiwillige Sie auf dem Wege zum Flugzeugentwickler mit volle Commit-Zugriff helfen kann.
Vor dem Erhalt von Commit-Zugriff sollte man alle Anstrengungen unternehmen, um die ursprünglichen Autoren eines Flugzeugs zu kontaktieren, um festzustellen, ob derzeit aktiv an dem Luftfahrzeug gearbeitet wird. Ist das nicht erfolgreich, dann solltest Du Dich auf der Entwickler-Mailingliste anmelden und dort um Hilfe bitten. Hier kann man außerdem allgemeine Hilfe bei Fragen rund um die Flugzeugentwicklung und um Commits bekommen.  


=== FGAddon Commitlog Mailingliste ===
=== FGAddon Commitlog Mailingliste ===


Um alle Änderungen im FGAddon Repository zu folgen, bitte an die dedizierte [https://lists.sourceforge.net/lists/listinfo/flightgear-fgaddon-commitlogs Flightgear FGAddon Commitlog Mailingliste] anmeldenEine E-Mail pro Commit wird gesendet, als das Commit gemacht wird.
Um allen Änderungen im FGAddon Repository zu folgen, ist es sinnvoll sich für die speziell eingerichtete  [https://lists.sourceforge.net/lists/listinfo/flightgear-fgaddon-commitlogs Flightgear FGAddon Commitlog Mailingliste] anzumeldenNach der Anmeldung bekommt man eine E-Mail, sobald ein neuer Commit veröffentlicht wird.
 
== Tools zur Versionskontrolle ==
 
Für Zugang zu dem FGAddon Repository, auf dem die Flugzeuge entwickelt werden sowie für die Subversion oder SVN Versionskontrolle, sind spezielle Werkzeuge nötig. Hier bietet git-svn eine Schnittstelle für alle, die lieber ihr eigenes Werkzeug für die git Versionskontrolle verwenden möchten.


== Versionskontroll-Werkzeuge ==
===Subversion===
==== Setup ====


Für Zugang an FGAddon um Flugzeuge zu entwickeln, die Subversion oder SVN Versionskontrolle Werkzeuge sind nötig.  Beziehungsweise bietet git-svn eine Schnittstelle für alle, die die git Versionskontrolle Werkzeuge lieber benutzen.
Der FGAddon Hangar wird in einem Remote-Subversion-Repository gespeichert, welcher Teil der SourceForge Infrastruktur ist. Aus diesem Grund ist es am einfachsten, ein SVN-Tool für die Flugzeugentwicklung zu nutzen. Auf diese Weise gibt es die wenigsten Probleme. Weitere Informationen über die Einrichtung einer Tool Chain gibt es in der der Sektion [[#Vorbereitung| Subversion Installation]].


=== Subversion ===
==== Der Repository checkout ====


==== Einrichtung ====
Der erste Schritt ist der sogenannte "Checkout" einer Kopie des Repository-Verzeichnisses oder des Flugzeug-Verzeichnisses in ihm. Dies ist auf folgende Weise möglich:
<syntaxhighlight lang="bash">
svn co <url> <dir>
</syntaxhighlight>


Der FGAddon Flugzeughangar findet sich in einem Subversion Remote-Repository, die auf SourceForge liegt.  Daher ist es am einfachsten und wird die am wenigsten Probleme geben, die SVN Werkzeuge für Flugzeugentwicklung zu benutzen. Sehe den [[#Vorbereitung|Subversion Installationsabschnitt]], um die Werkzeuge zu einrichten.
Um die für die Nutzung relevante URL zu erhalten, musst Du zunächst eines der [[#Entwicklungsszenarien|Entwicklungsszenarien]] auswählen und die URL in diesem Bereich suchen. Dieses Kommando erstellt dann eine lokale Kopie des Subversion Repositories im ausgewählten <code><dir></code> Verzeichnis. Beachte, dass auf diese Weise nur der Teil des FGAddon Repositories erstellt wird, der in der URL angegeben wurde. Das bedeutet, dass Subversion es ermöglicht, sowohl einzelne Dateien als auch komplette Repositorien bequen "auszuchecken".  


==== Repository auschecken ====
==== Information und History ====


==== Informationen und Geschichte ====
Es ist zu jederzeit möglich, genauere Information über ein lokales Repository anzeigen zu lassen. Hierfür kannst Du das folgende Kommando nutzen:
<syntaxhighlight lang="bash">
svn info
</syntaxhighlight>
 
Um die History mit Änderungen am Repository zu sehen, kannst Du eines der folgenden Kommandos nutzen:
<syntaxhighlight lang="bash">
svn log
svn log | less
svn log -v | less
</syntaxhighlight>


==== Tägliche Nutzung ====
==== Tägliche Nutzung ====
Das Subversion Kommando welches Du am meisten gebrauchen wirst, ist:
<syntaxhighlight lang="bash">
svn add <path>
</syntaxhighlight>
Es ermöglicht es Dir, eine Datei oder ein Verzeichnis <code><path></code> innerhalb eines lokalen Repositories zu registrieren. Dies ist der erste Schritt für einen späteren Commit, bei dem das entsprechende Verzeichnis bzw. die Datei an das serverseitige Repository geschickt wird.  Um ein Verzeichnis oder eine Datei zu verschieben oder umzubenennen, kannst Du das folgende Kommando nutzen:
<syntaxhighlight lang="bash">
svn mv <path1> <path2>
</syntaxhighlight>
Dies ist der bevorzugte Weg und das verschieben oder umbenennen von sollte immer auf diese Weise erfolgen, da so die Veränderungen im lokalen Repository erfasst und registriert werden. Um eine Datei aus dem lokalen Repository zu löschen, kannst Du dieses Kommando nutzen:
<syntaxhighlight lang="bash">
svn rm <path>
</syntaxhighlight>
Den aktuellen Status eines lokalen Repositories kannst Du einsehen, in dem Du dieses Kommando verwendest:
<syntaxhighlight lang="bash">
svn st
</syntaxhighlight>


==== Änderungen übergeben ====
Um ein lokales Repository mit aktuellen Änderungen auf dem Remote-Repositorium zu aktualisieren, kannst Du dieses Kommando verwenden:
<syntaxhighlight lang="bash">
svn up
</syntaxhighlight>


==== Verzweigen ====
==== Veränderungen an das Repository senden: Der Commit ====
 
Alle oben beschriebenen Operationen werden lediglich auf dem lokalen Repositorium, welches sich auf Deinem Computer befindet, ausgeführt. Das echte serverseitige Repository FGAddon bekommt von all dem – zumindest im Moment noch – nichts mit. Damit Deine aktuellen Änderungen an SourceForge und damit das Repository auf dem Server gesendet werden, ist ein sogenannter Commit erforderlich. Diesen kannst Du mit dem folgenden Kommando veranlassen:
<syntaxhighlight lang="bash">
svn ci
</syntaxhighlight>
 
Dieses Kommando öffnet einen Editor, der es Dir ermöglicht, ein kurzes aber informatives Log über Deinen Commit zu erstellen. Hier kannst Du den anderen Entwicklern mitteilen, welche Änderungen Du vorgenommen hast. Der Übersichtlichkeit halber ist es außerdem besser, stets mehrere kleinere Commits zu vollziehen, stat alles auf einmal an den Server zu schicken. Jeder Deiner Commits sollte dabei nur einem ganz bestimmten Zweck dienen. Beachte außerdem, dass Du nur dann Commits an FGAddon auf SourceForge schicken kannst, wenn Du über die entsprechenden [[#Commit Berechtigungen|Commit Berechtigungen]] verfügst. Änderungen an der lokalen Kopie des Repositoriums sind davon nicht betroffen.
 
==== Branching ====
 
Das Konzept des Branchings mit Subversion wird derzeit von FlightGear nur für das Tagging von stabilen Release-Versionen verwendet. Solltest Du aber neugierig sein und möchtest Du mehr über das Thema wissen, dann kannst Du Dir das [http://svnbook.red-bean.com/en/1.7/svn.branchmerge.html Branching und Merging Kapitel im Subversion Handbuch (Englisch)] oder das [https://www.orcaware.com/svn/wiki/Svnmerge.py svnmerge.py script] anschauen, um Dir den Vorgang und die Funktionsweise zu verdeutlichen.


=== Git-svn ===
=== Git-svn ===
Das git-svn Tool ist nützlich für diejenigen User, die bereits Erfahrung mit der Verwendung von Git-Repositories haben, aber auch für die User, die ihren eigenen Spielplatz zur Flugzeugentwicklung haben möchten. Git-svn schlägt eine Brücke zwischen dem Remote-FGAddon Subversion Repository auf dem SourceForge Server und dem lokal gespeicherten git Repositorium. Für diejenigen, die mit git nicht vertraut sind, sei an dieser Stelle erwähnt, dass die Nutzung von git zusammen mit git-svn um ein Vielfaches komplizierter ist als die Nutzung der nativen [[#Subversion|Subversion Tools]]. Für weitere Informationen über die Nutzung von git solltest Du Dir [[Howto:git für Anfänger]] anschauen. Das folgende Beispiel geht davon aus, dass nur ein einzelnes Flugzeug im lokalen git-Repositorium gespeichert werden soll.


==== Einrichtung ====
==== Einrichtung ====


==== Klonierung eines Flugzeug ====
Zunächst einmal ist es erforderlich das git-Werkzeug zur distribuierten Versionskontrolle zu installieren. Du findest es unter dem folgenden Link: [https://git-scm.com/downloads installed].
 
==== Ein einzelnes Flugzeug klonen ====
 
Im Folgenden siehst Du die notwendigen Schritte, um ein einzelnes Flugzeug aus dem Remote-Verzeichnis auf SourceForce lokal zu klonen: 
<syntaxhighlight lang="bash">
git svn clone <aircraft_url>
</syntaxhighlight>
 
Um die erforderliche Flugzeug-URL zu finden, must Du eines der [[#Development_scenarios|Entwicklungsszenarien]] verwenden. Du findest dort die URL in der entsprechenden Sektion. Sie ist abhängig von Deinem [[#Commit access|FGAddon Commit Zugang]]. Das Klon-Kommando erstellt ein lokales git-Repository, welches lediglich das ausgewählte Flugzeug enthält und startet die git-svn Brücke.
 
==== Information und Geschichte ====
 
Informationen über das lokale Repositorium erhälst Du mit dem folgenden Kommando:
<syntaxhighlight lang="bash">
git svn info
git branch -vva
git remote -v
</syntaxhighlight>
 
Um die Historie der ausgecheckten Kopie des Repositories anzuschauen, musst Du dieses Kommando nutzen:
<syntaxhighlight lang="bash">
git log
</syntaxhighlight>
 
==== Tägliche Verwendung ====
 
Das git Kommando, welches Du am meisten verwenden wirst ist dieses:
<syntaxhighlight lang="bash">
git add <path>
</syntaxhighlight>
 
Mit diesem Kommando registrierst Du die Datei oder das Verzeichnis <code><path></code> innerhalb deines lokalen Repositoriums. So ist später ein Commit in das lokale git-Repository möglich. Um eine Datei zu verschieben oder umzubenennen, kannst Du das folgende Kommando nutzen:
<syntaxhighlight lang="bash">
git mv <path1> <path2>
</syntaxhighlight>
 
Beachte dabei bitte, dass die git-Historie nicht so robust ist wie die, die Du von svn kennst. Siehe auch die [[#Dateien verschieben und löschen|git-svn Dateien verschieben und Löschen Sektion]], um in Erfahrung zu bringen, wie Du diese Operation am besten durchführen solltest. Um eine Datei aus dem lokalen Repository zu löschen, kannst Du das folgende Kommando nutzen:
<syntaxhighlight lang="bash">
git rm <path>
</syntaxhighlight>
 
Um den aktuellen Status eines lokalen Repositoriums zu betrachten, schreibe:
<syntaxhighlight lang="bash">
git status
</syntaxhighlight>
 
==== Der Commit – Änderungen senden ====
 
Da es sich bei git um ein distribuiertes Versionskontrollsystem handelt, müssen Änderungen in Form eines Commit an das git Repositorium gesendet werden. Dies erreichst Du mit dem folgenden Kommando:
<syntaxhighlight lang="bash">
git commit
</syntaxhighlight>
 
Es öffnet sich ein Editor-Fenster, welches es Dir ermöglicht eine Nachricht zu Deinem Commit zu hinterlassen. Beachte, dass dieser Commit ausschließlich lokal erfolgt und nicht an das FGAddon-Repository auf SourceForge geschickt wird.
 
==== Dedicated FGAddon branch ====
In the examples above, only a single branch was assumed in the repository.  If interaction with a remote git repository or branching within the local git repository is desired, then a different strategy is required.  The reason being that the branch that synchronises with FGAddon must [https://git-scm.com/book/en/v1/Git-and-Other-Systems-Git-and-Subversion#git-svn preserve a linear history].  This means only cherry-picking of the desired changes into that branch is allowed.


==== Informationen und Geschichte ====
In this example, two branches will be set up in the local git repository:
* <code>fgaddon</code>:  This branch will be dedicated for FGAddon synchronisation and will preserve a linear history.
* <code>master</code>:  A master branch for aircraft development, allowing for mergers and other non-linear history operations.
 
Assuming a [[#Cloning_a_single_aircraft|newly cloned repository]], create the <code>fgaddon</code> branch with:
<syntaxhighlight lang="bash">
git branch fgaddon
</syntaxhighlight>


==== Tägliche Nutzung ====
And switch to that branch:
<syntaxhighlight lang="bash">
git checkout fgaddon
</syntaxhighlight>
 
The FGAddon synchronisation can then be performed on this branch.  To pull in the developments from the master branch, use cherry-picking to apply a sequentially ordered list of commit hashes:
<syntaxhighlight lang="bash">
git cherry-pick <commit hash 1>
git cherry-pick <commit hash 2>
git cherry-pick <commit hash 3>
...
</syntaxhighlight>
 
To see the list of commits to be sent to FGAddon prior to dcommitting, type:
<syntaxhighlight lang="bash">
git log git-svn..HEAD
</syntaxhighlight>


==== Änderungen übergeben ====
And to see the changes as a single diff:
<syntaxhighlight lang="bash">
git diff git-svn..HEAD
</syntaxhighlight>


==== FGAddon dedizierte Zweig ====
==== Synchronising ====
To send the changes to the remote FGAddon repository, firstly change to the dedicated <code>fgaddon</code> branch:
<syntaxhighlight lang="bash">
git checkout fgaddon
</syntaxhighlight>


==== Synchronisierung ====
Make sure the local git-svn repository is up to date with all changes that have occurred in FGAddon:
<syntaxhighlight lang="bash">
git svn rebase
</syntaxhighlight>


Then push or dcommit the changes to FGAddon with:
<syntaxhighlight lang="bash">
git svn dcommit
</syntaxhighlight>
=== Nachteile des git-svn ===
=== Nachteile des git-svn ===



Revision as of 03:00, 4 September 2018

Die Übersetzung dieses Artikels ist in Bearbeitung.
FGAddon logo.png

Der offizielle FGAddon-Flugzeughangar ist ein Repository zur Versionskontrolle, der auf FlightGears SourceForge Infrastruktur gehostet ist und für die alltägliche Entwicklung der Flugzeuge von FlightGear verwendet wird. FGAddon ist ein Apache Subversion Version Control Repository. In FGAddon enthalten sind Flugzeuge, die nicht Teil des Basispaketes sind (im Basispaket enthalten sind die Cessna 172P und das UFO - Diese werden im FGData Repository gehostet), aber sie sind mit jeder stabilen Version für die FlightGear Downloadseiten (3.4.0, 3.6.0, etc.) markiert.

Die Flugzeuge, die im FGAddon-Repository entwickelt werden, sollten als instabil betrachtet werden. Bei der Verwendung einer stabilen Version von FlightGear, ist es am besten, ein Flugzeug mit der passenden Versionsnummer von der FlightGear-Downloadseite herunterzuladen. Allerdings sind die Flugzeuge in FGAddon seit FlightGear 3.4 mit jeder stabilen Version durch sog. "Tags" markiert, wodurch die Subversion-Werkzeuge ein praktisches Hilfsmittel sein können, um einzelne Flugzeuge oder den gesamten offiziellen Flugzeughangar von FlightGear mit ca. 500 Flugzeugen passend für die jeweilige stabile FlightGear-Version zu erhalten. Bei Verwendung des (täglich erstellten) FlightGear-Nightly-Builds oder einer selbst kompilierten FlightGear-Version aus den Git-Versionskontroll-Repositories ermöglicht FGAddon, die Flugzeuge passend zu den neuesten FlightGear-Entwicklungen zu erhalten.

Geschichte

Das FlightGear-Projekt wurde am 8. April 1996 von David Murr ins Leben gerufen, der die Idee zu einem neuen Flugsimulator hatte, welcher vollständig von Freiwilligen entwickelt wird.[1][2][3][4]. Ein Teil der ursprünglichen Ziele bestand darin, 2D- und 3D-Grafikroutinen für den Simulator zu entwickeln. Aber da dies eine gewaltige Aufgabe war, kam sie Anfang 1997 zu einem unfertigen Stillstand, als der Hauptentwickler Eric Korpela sich auf die Fertigstellung seiner Doktorarbeit konzentrieren wollte. Daher hat Curtis Olson am 16. Mai 1997 eine neue Entwicklung mit einem neuen Projekt auf der Basis der OpenGL-Bibliotheken begonnen, so dass ein funktioneller Flugsimulator in einer kurzen Zeitspanne zusammengefügt wurde.[5]. Die ersten Commits erfolgten zu den ursprünglichen flightgear und simgear CVS Versionskontrolle Repositories.

Durch das Wachstum des FlightGear-Projektes hat die Größe, Menge und Qualität der FlightGear Software-Assets ebenfalls zugenommen. Diese Assets waren nicht organisiert und wurden in verschiedenen Teilen des Internets verstreut. Daher wurde beschlossen, ein Großteil dieser FlightGear-Inhalte in einem neuen zentralen CVS-Repository zu sammeln und zu speichern, welches am 22. Oktober 2000 erstellt wurde und fgadata genannt wurde. Um die rechtliche Umverteilung dieser Assets als Teil der FlightGear-Distribution zu ermöglichen, wurde eine exklusive GPLv2 Politik angenommen.

Im Mai 2010 wurde die Entwicklung von dem berüchtigten "Kaffee-Zwischenfall" unterbrochen. Es führte zum Untergang des Heimservers von Curtis, der alle FlightGear Repositories gehostet hat[6]. Diese Ereignisse führten zu einer Massenmigration aller CVS-Repositories in neue Git-Repositories. Aufgrund von Problemen mit der Bandbreite wurde beschlossen, die neuen Repositories auf der Open-Source-Infrastruktur von Gitorious zu hosten.

Im Laufe der Zeit, während des Wachstums des FlightGear-Projekts, haben gleichzeitig die Größe und der Umfang des fgdata-Repos explosiv zugenommen, so dass eine Spaltung unvermeidlich war. Ein erster Spaltungsversuch wurde von Gijs de Rooy am 18. Oktober 2011 organisiert und angekündigt[7]. Jedes Flugzeug wurde in ein eigenes Git-Repository gestellt und alle Flugzeuge zurück an fgdata mit einem Git-Submodul Verfahren gebunden. Aber dieser Versuch scheiterte und wurde aufgegeben. Ab diesem Datum bis zum Ende des Jahres 2014 wurden die Pläne der Teilung von fgdata auf der Mailinglist der FlightGear-Entwickler diskutiert und im FlightGear Git: splitting fgdata Wiki-Artikel zusammengefasst. In der Planungsphase war das Repository als fgdata-old bekannt, das in FGData (auch bekannt als fgdata-new) und FGAddon (auch bekannt als flightgear-aircraft und fgaircraft) aufgeteilt wurde. Nach einem halben Jahrzehnt der Planung wurde beschlossen, dass die beste Lösung für FlightGear-Flugzeugentwicklung ein einziges zentrales Subversion-Repository wäre. Dies würde Gemeinschaftsentwicklung und Wartung der Flugzeuge erleichtern und zur gleichen Zeit Modularität, kleinere Downloads und kleinere lokale Repositories liefern.

Ende 2014 kündigte Gitorious, der Anbieter der Open-Source-Infrastruktur für den FlightGear Quellcode und die Daten-Repositories an, seine Dienstleistungen im Mai 2015 still zulegen. Grund war die Übernahme durch GitLab. Dies katalysierte die Spaltung von fgdata-old und einem Umzug zur Open-Source-Infrastruktur von SourceForge für das Hosting der VC-Repositories. Andere Teile der FlightGear-Infrastruktur waren bereits von Sourceforge gehostet, so dass dies ein natürlicher Schritt war. Um das Geschäft zu besiegeln, stimmte SourceForge schriftlich zu, die riesige FlightGear Flugzeugsammlung zu hosten, deren Größe in Open-Source-Kreisen konkurrenzlos ist. Heute ist das FGAddon SVN-Repository zusammen mit den meisten der FlightGear-Projekt-Infrastrukturen auf Sourceforge gehostet.

Im August 2015 wurde ein neues politisches Dokument über FlightGear verfasst, um die ungeschriebenen Normen des Projekts zu kodifizieren[8]. Mit diesem Dokument wurde die Lizenzpolitik für die FlightGear Flugzeuge von einer GPLv2-Verpflichtung, zu einer GPLv2+ oder GPL-kompatibel[9] Haltung aktualisiert. Allerdings wird zur Bekämpfung der Komplikationen durch Lizenz-Proliferation und für die Integrität und das Wohl des FlightGear-Projekts dringend empfohlen, neue Inhalte unter der GPLv2+ zu lizenzieren.

Flugzeuge bekommen

Hinweis  Solltest Du ausschließlich Interesse an Flugzeugen für stabile FlightGear-Versionen haben und keine Ahnung von Versionskontrolle haben, dann solltest Du die FlightGear Hangars besuchen, um Flugzeuge herunterzuladen.
Achtung  Bei unterschiedlichen Versionen von FlightGear den FGAddon-Flugzugen sind seltsame Fehler zu erwarten, da die Kombination von Flugzeugen und Software mit Versionskonflikten nicht von der FlightGear-Community unterstützt wird.

Mithilfe der Subversion-Werkzeuge (SVN-Tools) kann die Verwendung des FGAddon-Hangars eine einfache Methode sein um Flugzeuge für eine bestimmte FlightGear-Version direkt von der offiziellen Quelle zu erwerben. Bei der Verwendung des neuesten FlightGear Nightly Build oder einer selbst kompilierten Version von FlightGear sollten die neuesten Entwicklungsversionen der Flugzeuge verwendet werden, so dass die Versionen von Flugzeug und Software übereinstimmen. Aus der Perspektive eines FlightGear-Benutzers wird im Folgenden beschrieben, wie man das offizielle Repository verwenden sollte, um die gewünschten Flugzeuge zu erhalten.

Vorbereitung

Um das FGAddon-Repository zu verwenden, müssen die Subversion-Werkzeuge installieren werden:

  • MS Windows: Installiere eine der zahlreichen Subversion-Clients. Zum Beispiel ist SlikSVN eine der besten Versionen für die Kommandozeile und am Besten geeignetf für die Flugzeugentwicklung; TortoiseSVN bietet durch Integration in den Windows Explorer eine benutzerfreundliche Bedienung.
  • Mac OS X: Installiere das offizielle Subversion-Client.
  • GNU/Linux: Installiere das Subversion-Client durch den Package Manager. Es findet sich normalerweise in einem Paket, welches subversion-*.{rpm,deb} genannt wird.

Verzeichnisstruktur von FGAddon

Um zu verstehen, wie das FGAddon-Repository zu verwenden ist, ist ein Verständnis der Verzeichnisstruktur des Repositorys erforderlich.

  • /trunk: In diesem Basisverzeichnis befinden sich die Entwicklungsversionen der Flugzeuge.
  • /branches/release-x.y.z/: Diese Verzeichnisse enthalten die Flugzeuge für die jeweilige spezifische stabile FlightGear-Version.

Das Web-Interface für FGAddon auf Sourceforge ermöglicht es, alle Flugzeuge zu durchsuchen.

Herunterladen

Flugzeug zum Herunterladen

Wähle zuerst ein Flugzeug zum Herunterladen aus. In diesem Beispiel wird die V-22 Osprey von Boeing verwendet.

Kommandozeile

Um das Flugzeug für FlightGear 3.4 herunterzuladen, tippe einfach:

svn co https://svn.code.sf.net/p/flightgear/fgaddon/branches/release-3.4.0/Aircraft/V22-Osprey

Um die Entwickler-Version zu erhalten, gib folgendes ein:

svn co https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/V22-Osprey

Wenn Du alle Flugzeuge (ca.500) in der Entwicklungsversion aus dem Repository erhalten möchtest - Achtung, dies sind über 6 GB - benutzte den Befehl:

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

Bei Verwendung einer stabilen FlightGear-Version, z.B. FlightGear 2016.1, um alle Flugzeuge passend für FG 3.6 zu erhalten, benutzte:

svn co https://svn.code.sf.net/p/flightgear/fgaddon/branches/release-2016.1 flightgear-fgaddon

GUI-Clients und TortoiseSVN

Bei der Verwendung einer der Subversion-GUIs (grafische Benutzeroberflächen), kopiere eine der oben genannten https://-URLs in die GUI (jede GUI ist anders, also lies bitte die entsprechende Dokumentation). TortoiseSVN-Tool funktioniert da etwas anders:

  • Erstelle im Windows Explorer einen neuen leeren Ordner für das Flugzeug (oder die Flugzeugsammlung).
  • Klicke im neuen Ordner mit der rechten Maustaste und wähle SVN Checkout....
  • Kopiere und füge die URL ein, zum Beispiel https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/V22-Osprey, lass aber alle anderen Einstellungen unverändert, und lade die Dateien durch Klicken auf OK herunter.

Weitere Informationen findest Du in der TortoiseSVN-Dokumentation. Beachte, dass durch die Installation von TortoiseSVN die Möglichkeit besteht, die Kommandozeilen-Tools zu installieren.

Fliegen

Um die neuen heruntergeladenen Flugzeuge zu verwenden, empfiehlt es sich den Artikel Howto: Flugzeuge Installieren zu lesen. Die Anleitung zum Download und zum Entpacken des Flugzeugs kann mit dem Wissen aus diesem Artikel getrost übersprungen werden.

Aktualisierung der Flugzeuge

Mit einer Checkout-Kopie der /trunk-Entwicklungsversion, kannst Du das Flugzeug auf den neuesten Stand aktualisieren, indem Du folgenden Befehl eingibst:

svn up

Flugzeugentwicklung

Hinweis  Die FlightGear-Gemeinschaft fördert die Flugzeugentwicklung direkt im FGAddon Repository. Das macht die Arbeit einheitlich und für alle einfacher.

Kontakt mit den ursprünglichen Flugzeug Autoren

Der erste Schritt für die Entwicklung und Erweiterung von Flugzeugen des offiziellen FlightGear-Hangars, oder auch von einem der privaten Hangars, ist der Kontakt mit den ursprünglichen Flugzeug-Autor. Deren Namen können in der *-set.xml Datei innerhalb des <authors> XML-Tags gefunden werden. Oft werden ihre Kontakt-Email-Adressen in der README Datei oder in einer anderen Textdatei im Flugzeug Basisverzeichnis aufgelistet. Ist das nicht der Fall, kann der Kontakt manchmal durch die Mailinglist der FlightGear-Entwicklung hergestellt werden. Kontakt mit den ursprünglichen Autoren ist wichtig, um herauszufinden, ob ein Flugzeug in aktiver Entwicklung ist und ob Du Dich aktiv an der Entwicklung (vielleicht als Mitglied des Entwickler Teams) beteiligen kannst.

SourceForge Konto

Um an der offiziellen Flugzeugsammlung arbeiten zu können, sollte zunächst ein eigenes SourceForge Konto angelegt werden. Dies ist kostenlos und ermöglicht den direkten Commit-Zugriff auf das FGAddon Repository. Entsprechende Rechte müssen zunächst durch das SourceForge Entwicklungsteam zur Verfügung gestellt werden. Das Registrierungsverfahren ist schnell und unkompliziert erledigt. So bekommt man bereits nach wenigen Minuten vollen Zugriff auf alle Leistungen der Plattform sowie auf die verschiedenen Repositories von FlightGear.

Commit-Zugriff

Vor dem Erhalt von Commit-Zugriff sollte man alle Anstrengungen unternehmen, um die ursprünglichen Autoren eines Flugzeugs zu kontaktieren, um festzustellen, ob derzeit aktiv an dem Luftfahrzeug gearbeitet wird. Ist das nicht erfolgreich, dann solltest Du Dich auf der Entwickler-Mailingliste anmelden und dort um Hilfe bitten. Hier kann man außerdem allgemeine Hilfe bei Fragen rund um die Flugzeugentwicklung und um Commits bekommen.

FGAddon Commitlog Mailingliste

Um allen Änderungen im FGAddon Repository zu folgen, ist es sinnvoll sich für die speziell eingerichtete Flightgear FGAddon Commitlog Mailingliste anzumelden. Nach der Anmeldung bekommt man eine E-Mail, sobald ein neuer Commit veröffentlicht wird.

Tools zur Versionskontrolle

Für Zugang zu dem FGAddon Repository, auf dem die Flugzeuge entwickelt werden sowie für die Subversion oder SVN Versionskontrolle, sind spezielle Werkzeuge nötig. Hier bietet git-svn eine Schnittstelle für alle, die lieber ihr eigenes Werkzeug für die git Versionskontrolle verwenden möchten.

Subversion

Setup

Der FGAddon Hangar wird in einem Remote-Subversion-Repository gespeichert, welcher Teil der SourceForge Infrastruktur ist. Aus diesem Grund ist es am einfachsten, ein SVN-Tool für die Flugzeugentwicklung zu nutzen. Auf diese Weise gibt es die wenigsten Probleme. Weitere Informationen über die Einrichtung einer Tool Chain gibt es in der der Sektion Subversion Installation.

Der Repository checkout

Der erste Schritt ist der sogenannte "Checkout" einer Kopie des Repository-Verzeichnisses oder des Flugzeug-Verzeichnisses in ihm. Dies ist auf folgende Weise möglich:

svn co <url> <dir>

Um die für die Nutzung relevante URL zu erhalten, musst Du zunächst eines der Entwicklungsszenarien auswählen und die URL in diesem Bereich suchen. Dieses Kommando erstellt dann eine lokale Kopie des Subversion Repositories im ausgewählten <dir> Verzeichnis. Beachte, dass auf diese Weise nur der Teil des FGAddon Repositories erstellt wird, der in der URL angegeben wurde. Das bedeutet, dass Subversion es ermöglicht, sowohl einzelne Dateien als auch komplette Repositorien bequen "auszuchecken".

Information und History

Es ist zu jederzeit möglich, genauere Information über ein lokales Repository anzeigen zu lassen. Hierfür kannst Du das folgende Kommando nutzen:

svn info

Um die History mit Änderungen am Repository zu sehen, kannst Du eines der folgenden Kommandos nutzen:

svn log
svn log | less
svn log -v | less

Tägliche Nutzung

Das Subversion Kommando welches Du am meisten gebrauchen wirst, ist:

svn add <path>

Es ermöglicht es Dir, eine Datei oder ein Verzeichnis <path> innerhalb eines lokalen Repositories zu registrieren. Dies ist der erste Schritt für einen späteren Commit, bei dem das entsprechende Verzeichnis bzw. die Datei an das serverseitige Repository geschickt wird. Um ein Verzeichnis oder eine Datei zu verschieben oder umzubenennen, kannst Du das folgende Kommando nutzen:

svn mv <path1> <path2>

Dies ist der bevorzugte Weg und das verschieben oder umbenennen von sollte immer auf diese Weise erfolgen, da so die Veränderungen im lokalen Repository erfasst und registriert werden. Um eine Datei aus dem lokalen Repository zu löschen, kannst Du dieses Kommando nutzen:

svn rm <path>

Den aktuellen Status eines lokalen Repositories kannst Du einsehen, in dem Du dieses Kommando verwendest:

svn st

Um ein lokales Repository mit aktuellen Änderungen auf dem Remote-Repositorium zu aktualisieren, kannst Du dieses Kommando verwenden:

svn up

Veränderungen an das Repository senden: Der Commit

Alle oben beschriebenen Operationen werden lediglich auf dem lokalen Repositorium, welches sich auf Deinem Computer befindet, ausgeführt. Das echte serverseitige Repository FGAddon bekommt von all dem – zumindest im Moment noch – nichts mit. Damit Deine aktuellen Änderungen an SourceForge und damit das Repository auf dem Server gesendet werden, ist ein sogenannter Commit erforderlich. Diesen kannst Du mit dem folgenden Kommando veranlassen:

svn ci

Dieses Kommando öffnet einen Editor, der es Dir ermöglicht, ein kurzes aber informatives Log über Deinen Commit zu erstellen. Hier kannst Du den anderen Entwicklern mitteilen, welche Änderungen Du vorgenommen hast. Der Übersichtlichkeit halber ist es außerdem besser, stets mehrere kleinere Commits zu vollziehen, stat alles auf einmal an den Server zu schicken. Jeder Deiner Commits sollte dabei nur einem ganz bestimmten Zweck dienen. Beachte außerdem, dass Du nur dann Commits an FGAddon auf SourceForge schicken kannst, wenn Du über die entsprechenden Commit Berechtigungen verfügst. Änderungen an der lokalen Kopie des Repositoriums sind davon nicht betroffen.

Branching

Das Konzept des Branchings mit Subversion wird derzeit von FlightGear nur für das Tagging von stabilen Release-Versionen verwendet. Solltest Du aber neugierig sein und möchtest Du mehr über das Thema wissen, dann kannst Du Dir das Branching und Merging Kapitel im Subversion Handbuch (Englisch) oder das svnmerge.py script anschauen, um Dir den Vorgang und die Funktionsweise zu verdeutlichen.

Git-svn

Das git-svn Tool ist nützlich für diejenigen User, die bereits Erfahrung mit der Verwendung von Git-Repositories haben, aber auch für die User, die ihren eigenen Spielplatz zur Flugzeugentwicklung haben möchten. Git-svn schlägt eine Brücke zwischen dem Remote-FGAddon Subversion Repository auf dem SourceForge Server und dem lokal gespeicherten git Repositorium. Für diejenigen, die mit git nicht vertraut sind, sei an dieser Stelle erwähnt, dass die Nutzung von git zusammen mit git-svn um ein Vielfaches komplizierter ist als die Nutzung der nativen Subversion Tools. Für weitere Informationen über die Nutzung von git solltest Du Dir Howto:git für Anfänger anschauen. Das folgende Beispiel geht davon aus, dass nur ein einzelnes Flugzeug im lokalen git-Repositorium gespeichert werden soll.

Einrichtung

Zunächst einmal ist es erforderlich das git-Werkzeug zur distribuierten Versionskontrolle zu installieren. Du findest es unter dem folgenden Link: installed.

Ein einzelnes Flugzeug klonen

Im Folgenden siehst Du die notwendigen Schritte, um ein einzelnes Flugzeug aus dem Remote-Verzeichnis auf SourceForce lokal zu klonen:

git svn clone <aircraft_url>

Um die erforderliche Flugzeug-URL zu finden, must Du eines der Entwicklungsszenarien verwenden. Du findest dort die URL in der entsprechenden Sektion. Sie ist abhängig von Deinem FGAddon Commit Zugang. Das Klon-Kommando erstellt ein lokales git-Repository, welches lediglich das ausgewählte Flugzeug enthält und startet die git-svn Brücke.

Information und Geschichte

Informationen über das lokale Repositorium erhälst Du mit dem folgenden Kommando:

git svn info
git branch -vva
git remote -v

Um die Historie der ausgecheckten Kopie des Repositories anzuschauen, musst Du dieses Kommando nutzen:

git log

Tägliche Verwendung

Das git Kommando, welches Du am meisten verwenden wirst ist dieses:

git add <path>

Mit diesem Kommando registrierst Du die Datei oder das Verzeichnis <path> innerhalb deines lokalen Repositoriums. So ist später ein Commit in das lokale git-Repository möglich. Um eine Datei zu verschieben oder umzubenennen, kannst Du das folgende Kommando nutzen:

git mv <path1> <path2>

Beachte dabei bitte, dass die git-Historie nicht so robust ist wie die, die Du von svn kennst. Siehe auch die git-svn Dateien verschieben und Löschen Sektion, um in Erfahrung zu bringen, wie Du diese Operation am besten durchführen solltest. Um eine Datei aus dem lokalen Repository zu löschen, kannst Du das folgende Kommando nutzen:

git rm <path>

Um den aktuellen Status eines lokalen Repositoriums zu betrachten, schreibe:

git status

Der Commit – Änderungen senden

Da es sich bei git um ein distribuiertes Versionskontrollsystem handelt, müssen Änderungen in Form eines Commit an das git Repositorium gesendet werden. Dies erreichst Du mit dem folgenden Kommando:

git commit

Es öffnet sich ein Editor-Fenster, welches es Dir ermöglicht eine Nachricht zu Deinem Commit zu hinterlassen. Beachte, dass dieser Commit ausschließlich lokal erfolgt und nicht an das FGAddon-Repository auf SourceForge geschickt wird.

Dedicated FGAddon branch

In the examples above, only a single branch was assumed in the repository. If interaction with a remote git repository or branching within the local git repository is desired, then a different strategy is required. The reason being that the branch that synchronises with FGAddon must preserve a linear history. This means only cherry-picking of the desired changes into that branch is allowed.

In this example, two branches will be set up in the local git repository:

  • fgaddon: This branch will be dedicated for FGAddon synchronisation and will preserve a linear history.
  • master: A master branch for aircraft development, allowing for mergers and other non-linear history operations.

Assuming a newly cloned repository, create the fgaddon branch with:

git branch fgaddon

And switch to that branch:

git checkout fgaddon

The FGAddon synchronisation can then be performed on this branch. To pull in the developments from the master branch, use cherry-picking to apply a sequentially ordered list of commit hashes:

git cherry-pick <commit hash 1>
git cherry-pick <commit hash 2>
git cherry-pick <commit hash 3>
...

To see the list of commits to be sent to FGAddon prior to dcommitting, type:

git log git-svn..HEAD

And to see the changes as a single diff:

git diff git-svn..HEAD

Synchronising

To send the changes to the remote FGAddon repository, firstly change to the dedicated fgaddon branch:

git checkout fgaddon

Make sure the local git-svn repository is up to date with all changes that have occurred in FGAddon:

git svn rebase

Then push or dcommit the changes to FGAddon with:

git svn dcommit

Nachteile des git-svn

Kopieren von Dateien zwischen Flugzeuge

Verschieben oder Umbenennen von Dateien

Kopieren von Dateien innerhalb eines Flugzeuges

FGAddon Entwicklungskonzepte

Neue Flugzeuge

svn import

svn add

Mime-type Probleme

Subversion config Datei

Ausführungs Bit

Sourceforge Entwickler Dienstleistungen

Entwickler Git Repository

Entwicklungsteams

Kommunikation im Team

Entwicklungsszenarien

Einzel-Entwickler

Einzel-Entwickler (git-svn)

Auf SourceForge hochladen

Sendung von externen Git Repository Änderungen auf FGAddon

Anschluss ein bestehendes Git Repository an FGAddon

Teamentwicklung

Private Teamentwicklung (git-svn)

Das Team

Teamleiter

Privates Repository Einrichtung
Team Einrichtung
Hochladung auf FGAddon

Teammitgliedern

Arbeiten mit dem Repository
Forking und merge requests

Referenzen

  1. David Murr (Apr 9, 1996). FlightGear Antrag 1.0: "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@". Veröffentlicht auf der rec.aviation.simulators Newsgroup.
  2. David Murr (1996). FlightGear Antrag 2.0: FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0.
  3. David Murr (Oct 29, 1996). FlightGear Antrag 3.0: FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here". Publiziert auf der flight-gear@infoplane.com Verteilerliste.
  4. David Murr (Sep 11, 1998). FlightGear Antrag 3.0.1: FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here".
  5. Curtis Olson (Sep 28, 2015). Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@. Veröffentlicht im FlightGear-Forum.
  6. James Turner (May 20, 2010). [Flightgear-devel] Re: Flightgear git repositories (was Re: GIT or CVS - Confusion) Veröffentlicht auf der flightgear-devel Mailinglist.
  7. Cedric Sodhi (Oct 18, 2011) [Flightgear-devel] FGData Split Completed - a.k.a Life after the Split Veröffentlicht auf der flightgear-devel Mailinglist.
  8. FlightGear Policy Document and Roadmap, Entwurfsdokument.
  9. GNU-Lizenz Kompatibilitätsliste.