De/FGAddon

Die Übersetzung dieses Artikels ist in Bearbeitung.

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.. 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.. 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. 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. 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. Mit diesem Dokument wurde die Lizenzpolitik für die FlightGear Flugzeuge von einer GPLv2-Verpflichtung, zu einer GPLv2+ oder GPL-kompatibel 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.

Dezidierte FGAddon Branch

In unserem obigen Beispiel haben wir angenommen, dass sich lediglich eine einzelne Branch im dem Repository befindet. Soll eine Interaktion mit dem Remote-Git-Repositorium oder ein Branching innerhalb des lokalen Repos erfolgen, dann ist ein anderes Vorgehen erforderlich. Der Grund dafür ist, das eine Branch die mit FGAddon synchronisiert werden soll eine lineare Historie aufweisen muss. Mehr Informationen dazu findet man zum Beispiel hier (Englisch): preserve a linear history. Das bedeutet im Einzelnen, dass nur das sogenannte "Cherry-Picking" von gewünschten Änderungen in die Branch erlaubt ist.

In diesem Beispiel werden zwei Branches als lokales git Repositorium eingerichtet:

• fgaddon: Diese Branch wird ausschließlich der Synchronisation mit FGAddon dienen und wird eine lineare Historie beibehalten.
• master: Eine Master-Branch für die Flugzeugentwicklung. Sie ermöglicht Merger und andere nicht linerare Operationen, die in der obigen Branch nicht möglich sind, da eine linearer Verlauf beibehalten werden muss.

Gehen wir von einem neu geklonten Repositorium aus, dann kann man die fgaddon Branch mit dem folgenden Kommando erstellen:

git branch fgaddon

Der Wechsel zu dieser neuen Branch erfolgt mit:

git checkout fgaddon

Die Synchronisation mit FGAddon kann über diese Branch erfolgen. Um neue Entwicklungsfortschritte von der Master Branch zu pullen, kannst Du "Cherry-Picking" nutzen, um eine sequentiell geordnete Liste von Commit-Hashes zu senden:

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

Um eine Liste der Commits zu sehen, die an FGAddon geschickt werden, bevor der tatsächliche Commit ausgeführt wird, kannst Du dieses Kommando nutzen:

git log git-svn..HEAD

Und um die Änderungen in einer einzelnen diff zu sehen, schreibst Du:

git diff git-svn..HEAD

Synchronisierung

Um die Änderungen an das Remote-FGAddon-Repository zu senden, musst Du zunächst zu der dezidierten fgaddon Branch wechseln (siehe oben):

git checkout fgaddon

Stelle sicher, dass das lokale git-svn Repositorium auf dem aktuellen Stand ist und alle Änderungen die an FGAddon durchgeführt wurden, enthält:

git svn rebase

Dann kannst Du einen Push oder ein dcommit ausführen um Deine eigenen Änderungen an FGAddon zu senden:

git svn dcommit

Nachteile des git-svn

Warnung  Es ist nicht empfohlen, einen git-svn clone des Verzeichnisstammes /trunk/ oder des gesamten Repositoriums, durchzuführen. Dies führt dazu, dass der gesamte Repo-Verlauf heruntergeladen wird. Die Folge ist ein riesiges Repository und wirkt sich zudem nachteilig auf die Infrastruktur des FlightGear Repositoriums aus.

Es ist wichtig, zu verstehen dass git-svn zahlreiche Nachteile aufweise bzw. in einigen Bereich weniger effizient arbeiten kann. In den meisten Fällen ist es in solchen Situationen ratsam, stattdessen die "SVN Tools" zu verwenden.

Kopieren von Dateien zwischen Flugzeugen

Achtung  Git-svn verfügt über einen Verlauf der kopierten Dateien, wie er normalerweise in Suversion-Repositorien vorhanden ist!

Der wichtigste Schritt ist das Kopieren von anderen FGAddon Flugzeugen. In diesem Fall benötigst Du Commit-Berechtigungen für das FGAddon Repository sowie eine lokale Kopie desselben. Als erstes muss Du nun die Repositories sychronisieren, indem Du alle aktuellen Änderen mit einem "dcommit" zurück an FGAddon schickst:

git svn dcommit

Anschließend kannst Du die gewünschte Datei im lokalen Repositorium kopieren:

svn cp Aircraft/<aircraft1>/<file_path1> Aircraft/<aircraft2>/<file_path2>

Und die Änderungen durch einen Commit durchführen:

svn ci

Zurück im lokalen git-svn Repositorium kannst Du nun alle notwendigen Dateien pullen:

git svn rebase

Durch die Nnutzung der Subversion Tools kannst Du verhindern, dass das Backend des FGAddon Repositoriums zu stark anwächst. Mehr Informationen dazu findest Du hier (Englisch): svn copies are cheap.

Verschieben oder Umbenennen von Dateien

Achtung  Git-svn erzeugt nicht immer einen Verlauf für das Verschieben oder Umbenennen von Dateien, wie es normalerweise bei einem Subversion Repository der Fall ist.

Das Problem basiert darauf, dass der SVN Verlauf deutlich robuster ist, als der von Git. Die svn mv und git mv Kommandos sind nicht identisch. Das Subversion Kommando speichert den Verlauf des Verschhiebens direkt im entsprechenden Repositorium. Git tut das jedoch nicht. Stattdessen verwendet Git heuristische Methoden, und versucht so den Verlauf nach dem Commit zu entdecken. Die Nutzung von SVN-Git führt also dazu, dass das Verschieben nicht registriert wird. Der FGAddon Verlauf zeigt stattdessen das eine Datei oder ein Verzeichnis gelöscht, während eine andere Datei bzw. ein anderes Verzeichnis neu angelegt wurde. Das führt außerdem dazu, dass die Größe des Backends des Repositoriums zunimmt. Das svn mv Kommando hingegen führt zu keinem nennenswerten Anstieg der Größe beim Repository-Backend. Möchtest Du einen besseren historischen Verlauf im FGAddon Reposity haben und gleichzeitig verantwortungsvoll mit der Backend-Größe umgehen, dann is es zu empfehlen, vorrübergehend zu den Subversion Tools zu wechseln. Dafür musst Du zunächst die Repositorien synchronisieren:

git svn dcommit

Anschließend kannst Du die Datei oder das Verzeichnis im lokalen Repo verschieben oder umbennen:

svn mv Aircraft/<aircraft>/<file_path1> Aircraft/<aircraft>/<file_path2>

Und einen Commit für die Änderungen durchführen:

svn ci

Zurück im lokalen Git-SVN Repositorium kannst Du nun die Änderungen "pullen":

git svn rebase

Copying files within one aircraft

Just as the svn mv command stores the move information directly within the repository, so does svn cp store the copy information. Therefore if you would like to duplicate a text file and modify it, using the native Subversion tools instead of git-svn for this operation allows for the file history to be permanently preserved in the FGAddon repository.

Subversion properties

Achtung  Git-svn currently only supports the svn:executable property, all other properties are ignored and cannot be added, changed, or removed in a git-svn clone of the aircraft.

Internally, Subversion identifies binary files using the svn:mime-type repository property. However as git-svn cannot set this property when using the git add command, the result is that binary files will be treated as text. Binary diffs will be seen when using svn diff or git diff, and a binary diff will be shown in the FGAddon commitlog mailing list messages. As this issue is not unique to git-svn, to work around this issue please see the binary diffs section.

Protocols other than svn+ssh

The command git svn init replicates the entire history of an aircraft into a local repository. As part of this process, it generates a git commit ID or hash for every Subversion revision. The problem is that the git commit ID depends on the protocol used to read from the Subversion repository (likely a git bug). Hence:

git svn init svn+ssh://<username>@svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/<aircraft>

and

git svn init https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/<aircraft>

will result in two different and incompatible git repositories, even though they contain the same data. The incompatibility is not immediately apparent but it will bite later. Suppose someone with read-only access to FGAddon uses the https method, then asks a FGAddon gatekeeper to commit their changes. The gatekeeper, naturally, uses svn+ssh, as this is the only protocol granting write permissions. When the gatekeeper tries to merge the contributor's https clone into their own svn+ssh clone, git will complain that the two repositories have no history in common, and flag every change as a conflict.

Therefore, if you are planning to make any changes to an aircraft, be sure to use svn+ssh even if you do not yet have commit permissions on FGAddon. svn+ssh does not require write permissions, it only requires a SourceForge user ID.