Nl/FGAddon

This article is currently being translated.

Kees (talk) 08:06, 29 January 2018 (EST)

De officiële FGAddon vliegtuighangar is een versie beheer systeem, gehost op de SourceForge infrastructure van Nl/FlightGear en wordt gebruikt voor de continue ontwikkeling van FlightGear-vliegtuigen. FGAddon is een Apache Subversion versiebeheer opslaglocatie. Dit zijn vliegtuigen die geen deel uitmaken van het basispakket (de vliegtuigen die in het basispakket zijn opgenomen - de Nl/Cessna_172P en de UFO - worden in het FGData repository bewaard), maar worden gemarkeerd met elke stabiele release voor de FlightGear download pages.

Het FGAddon-ontwikkelingscentrum voor vliegtuigen moet als onstabiel worden beschouwd. Wanneer je een stabiele FlightGear-release gebruikt, kun je het beste een vliegtuig met een overeenkomstig versienummer van de FlightGear download pages gebruiken. Echter, aangezien stabiele releases van FlightGear versie 3.4 en volgende van FlightGear worden gelabeld en aanwezig zijn in de opbergruimte van het FGAddon, kunnen de Subversion tools een handige manier zijn om individuele vliegtuigen of het complete aanbod van ongeveer 500 vliegtuigen te verkrijgen.Ook als je gebruik maakt van lastest nightly releases of een self-compiled version of FlightGear van Git version control repositories, maakt het gebruik van FGAddon het mogelijk om het vliegtuig te updaten naar de nieuwste ontwikkelversie.

Geschiedenis

Original Win95 icon

Het FlightGear-project werd op 8 april 1996 bedacht door David Murr, die een nieuwe vluchtsimulator voorstelde die geheel door vrijwilligers zou worden ontwikkeld. . . Een deel van de aanvankelijke doelstellingen was het ontwikkelen van 2D- en 3D grafische routines voor de simulator. Dit was echter een enorme taak die begin 1997 onafgewerkt tot stilstand kwam omdat de hoofdontwikkelaar, Eric Korpela, zijn proefschrift aan het afronden was. Daarom heeft Curtis Olson vanaf 16 mei 1997 de ontwikkeling opnieuw opgestart met een nieuw project op basis van OpenGL-bibliotheken, waardoor in korte tijd een functionele vluchtsimulator kon worden samengesteld. . De eerste resultaten hadden betrekking op de oorspronkelijke flightgear and simgear CVS version control repositories.

Naarmate het project groeide, nam ook de omvang, kwantiteit en kwaliteit van de FlightGear-onderdelen toe. Deze onderdelen waren niet logisch geordend en waren verspreid over verschillene onderdelen op het internet. Daarom werd besloten dat een groot deel van deze FlightGear-inhoud zou worden samengevoegd en opgeslagen in een nieuwe gecentraliseerde CVS-repository, fgdata genaamd, die op 22 oktober 2000 werd gecreëerd. Om de juridische herverdeling van deze activa in het kader van de FlightGear verspreiding mogelijk te maken, werd alleen een GPLv2-beleid aangenomen.

In mei 2010 werd de ontwikkeling onderbroken door het beruchte "koffie-incident" dat leidde tot het verlies van Curtis' thuis-server met alle FlightGear-repositysites . Deze gebeurtenissen hebben geleid tot een mass migration of all the CVS repositories to Git repositories. Vanwege bandbreedteproblemen werd besloten om de nieuwe repositories te hosten op de open source infrastructuur van Gitorious.

Naarmate het project groeide, nam de omvang en omvang van de fgdata repository toe, vooral door het groeiende aantal vliegtuigen opgeslagen in $FG_ROOT/Aircraft, waardoor een splitsing onvermijdelijk was. Een eerste splitsingspoging werd georganiseerd door Gijs de Rooy en op 18 oktober 2011 aangekondigd . Elk vliegtuig werd in zijn eigen Git-repository geplaatst en alle vliegtuigen werden met behulp van een Git-submodulebenadering terug gekoppeld naar fgdata. Deze poging mislukte echter en werd gestopt. Vanaf deze datum tot eind 2014 werd het ontwerp van de fgdata splitsing besproken op de ontwikkelmailinglijst en samengevat in een FlightGear Git: splitting fgdata wiki artikel. In de planningsfasen stonden de repositories bekend als fgdata-oud en gesplitst in FGData (ook bekend als fgdata-nieuw) en FGAddon (ook bekend als flightgear-aircraft en fgaircraft). Na een half decennium van planning werd besloten dat de ontwikkeling van FlightGear-vliegtuigen via een centrale repository op het Subversion (SVN) versiebeheersysteem de beste oplossing zou zijn. Dit zou het communautair beheer en het onderhoud van het vliegtuig vergemakkelijken en tegelijkertijd zorgen voor modulariteit en kleinere downloads en kleinere lokale repositories.

Eind 2014 kondigde Gitorious, de aanbieder van de open-source-infrastructuur voor de FlightGear source code en data repositories, aan dat het zijn diensten tegen mei 2015 zou sluiten vanwege de overname door GitLab. Dit was de aanzet voor een versnelde splitsing van fgdata-oud en een overstap naar de SourceForge open source infrastructuur voor het hosten van de VC repositories. Andere delen van de FlightGear-infrastructuur werden al gehost door SourceForge, waardoor de verhuizing een logische stap werd. SourceForge stemde er schriftelijk mee in om de enorme FlightGear vliegtuigcollectie te hosten, waarvan de grootte ongeëvenaard is in open-sourcekringen. Vandaag de dag wordt de FGAddon SVN repository, samen met het grootste deel van de FlightGear projectinfrastructuur, gehost op SourceForge. In augustus 2015 werd een nieuw FlightGear-beleidsdocument opgesteld om de ongeschreven normen van het project vast te leggen . Met dit document is het licentiebeleid voor de FlightGear-vliegtuigen die op FGAddon worden gehost, opgewaardeerd van GPLv2-only naar GPLv2+. Om de licentie proliferatie tegen te gaan, complicaties te vermijden door werk vanuit het ene vliegtuig in het andere te gebruiken, en omwille van de integriteit en het welzijn van het FlightGear-project, wordt sterk aanbevolen dat alle originele inhoud (zowel die wordt gehost in FGAddon of elders) gebruik maakt van een GPLv2+ licentie.

Het verkrijgen van vliegtuigen

Tip  Als je graag andere vliegtuigen voor een stabiele FlightGear release zou willen en als je niet op de hoogte bent van een versiebeheersysteem, moet je de FlightGear hangars bezoeken om vliegtuigen te downloaden.

Let op  Als de FlightGear- en FGAddon-versies van vliegtuigen niet met elkaar overeenkomen, kun je vreemde bugs verwachen en zal de versie-mismatch van deze combinatie niet worden ondersteund door de FlightGear-community.

Met toegang tot de Subversion (Subversion (SVN) tools kan de FGAddon versie control repository een handige manier zijn om vliegtuigen te verkrijgen voor gebruik binnen een specifieke FlightGear versie rechtstreeks van de officiële bron. Bij gebruik van de nightly builds of een version controlled copy of FlightGear, moet je de meest recente versie van het vliegtuig in ontwikkeling gebruiken zodat de versies overeenkomen. Hieronder wordt beschreven hoe je als FlightGear gebruiker de officiële repository kunt gebruiken om vliegtuigen te verkrijgen.

Voorbereiding

Om de FGAddon-repository te kunnen gebruiken, moet Subversion geïnstalleerd worden:

• MS Windows: Installeer een van many Subversion clients. Bij voorbeeld SlikSVN is een van de beste commandoregelversies en de beste voor vliegtuigontwikkeling en TortoiseSVN biedt een gebruiksvriendelijke grafische gebruikersinterface (GUI) door de integratie in Windows Explorer.
• Mac OS X: Installeer de official Subversion client.
• GNU/Linux: Installeer de Subversion client via de package manager. Dit zal gewoonlijk een pakket zijn met de naam subversion-*.{rpm,deb}.

FGAddon mappen structuur

Om te weten hoe je de FGAddon repository moet gebruiken, is een goed begrip van de opzet van de repository directory essentieel.

• /trunk: In deze basismap zitten de in ontwikkeling zijnde versies van het vliegtuig.
• /branches/release-x.y.z/: Deze directories/mappen komen overeen met de specifieke stabiele FlightGear releases.

De web interface for the FGAddon repository maakt het mogelijk een overzicht van alle vliegtuigen te krijgen.

Downloaden

Aircraft to be downloaded

Kies eerst een vliegtuig om te downloaden. In dit voorbeeld zullen we de Bell Boeing V-22 Osprey gebruiken.

Command line

Om dit vliegtuig voor FlightGear 3.4 te downloaden, type je in:

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

Om de in ontwikkeling zijnde versie te verkrijgen, gebruik je:

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

Als je alle ~500 vliegtuigen uit de repository wil hebben - pas op dat dit een enorme download van meer dan 6 GB zal zijn - gebruik dan de volgende opdracht:

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

Wanneer je een stabiele FlightGear release gebruikt, bijvoorbeeld FlightGear 2016.1, om alle FGAddon-vliegtuigen te laten overeenkomen met de geïnstalleerde FlightGear-versie, gebruik dan:

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

GUI cliënten en TortoiseSVN

Wanneer je een van de GUI's van Subversion gebruikt (GUI = grafische gebruikersinterfaces), kopieer dan gewoon een van de bovenstaande URL's van https:// en gebruik deze in de GUI (elke GUI is anders, zie de relevante documentatie voor hulp). Voor de unieke TortoiseSVN tool:

• Maak in Windows Verkenner een nieuwe, lege map aan voor het vliegtuig (of voor de vliegtuigcollectie)
• Klik met de rechtermuisknop in de nieuwe map en selecteer SVN Checkout...
• Kopieer en plak de URL, bijvoorbeeld https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/V22-Osprey, laat alle andere instellingen zoals ze zijn en importeer door op OK te klikken.

Zie voor meer details de TortoiseSVN documentation. Houd er rekening mee dat er een optie is om de commandoregeltools te installeren bij het installeren van TortoiseSVN.

Vliegen

Om het nieuw gedownloade vliegtuig te gebruiken, raadpleeg je het artikel Howto:Install aircraft, waarbij je de instructies voor het downloaden en uitpakken van het vliegtuig overslaat.

Updaten

Met een uitgecheckte versie van de /trunk ontwikkelversie kan het vliegtuig worden bijgewerkt naar de laatste versie, met het commando:

svn up

Ontwikkelen van vliegtuigen

Tip  De FlightGear-gemeenschap stimuleert de ontwikkeling van vliegtuigen rechtstreeks binnen FGAddon.

Contact met de oorspronkelijke vliegtuigontwikkelaars

De eerste stap om vliegtuigen van de officiële FlightGear hangar of overigens afkomstig uit een van de private hangars te ontwikkelen en vooruit te helpen is het contact leggen met de oorspronkelijke ontwikkelaar(s) van het vliegtuig. Hun namen zijn te vinden in het *-set.xml bestand, binnen de <authors> XML tag. Vaak wordt het e-mailadres van de contactpersoon vermeld in een README-bestand of een ander tekstbestand in de bestandenmap van het betreffende vliegtuig. Zo niet, dan kan soms contact worden opgenomen via FlightGear development mailing list. Contact opnemen met de oorspronkelijke auteurs is belangrijk om te zien of het vliegtuig momenteel actief in ontwikkeling is en of je als onderdeel van het ontwikkelteam mee kunt doen.

SourceForge account

Om aan de officiële vliegtuigcollectie te werken, moet eerst een SourceForge-account worden aangemaakt. Dit zal het mogelijk maken, zodra toegang is verleend, om ofwel direct bijdragen te leveren via de FGAddon repository of om te werken als onderdeel van een SourceForge-ontwikkelteam. Het registratieproces neemt zeer weinig tijd in beslag en de SourceForge ontwikkel-infrastructuur en ontwikkelaarsdiensten zijn in minder dan een minuut toegankelijk.

Commit access/Toelating

Voordat je toegang tot "commit" krijgt, moet je alles in het werk stellen om contact op te nemen met de oorspronkelijke auteur(s) om zeker te weten dat het vliegtuig van jouw keuze actief wordt ontwikkeld. Als dit niet lukt, meld je dan aan voor de Flightgear FGAddon commitlogs mailing list en vraag daar om hulp. Als het vliegtuig een actieve ontwikkelaar heeft, zal worden aangegeven hoe je aan de ontwikkeling kunt bijdragen. Vraag anders of iemand je vrijwillig kan begeleiden in het proces om een vliegtuigontwikkelaar te worden met volledige commit toegang.

Om toegang te krijgen tot commit, zul je eerst:

1. Jouw capaciteiten en ontwikkelingvaardigheden moeten aantonen.
2. Moeten duidelijk maken dat je het flightgear policy document begrijpt.
3. Moeten laten zien dat je de GPL-licentieproblemen begrijpt en dat je te geen auteursrechtelijk beschermd, niet-GPL-materiaal zult gebruiken.
4. Het vertrouwen van de FlightGear-gemeenschap verdient.

Deze eenvoudig te nemen hindernissen zijn ontworpen om de database te beschermen tegen beschadiging of vervuiling door illegale inhoud.

Om jouw wijzigingen in de FGAddon database te laten vastleggen, moet je afstemmen met de oorspronkelijke vliegtuigontwikkelaar of met jouw mentor, hoe je dat het beste kunt regelen. Afhankelijk van het ontwikkelingsscenario kan dit door samenvoeging van aanvraag, bestandsoverdracht, het primitieve patchsysteem of op een andere handige manier. Zodra je denkt dat je jouw capaciteiten hebt bewezen en dat je op de hoogte bent van GPL-licentieproblatiek is het zaak je een bericht te sturen naar de mailinglijst voor ontwikkelaars met de vraag of je toegang kunt krijgen en tegelijkertijd een SourceForge-gebruikersnaam doorgeven.

FGAddon commitlog mailinglijst

Om alle wijzigingen te volgen die zich voordoen in de FGAddon-repository, moet je je abonneren op de speciale Flightgear FGAddon commitlogs mailing list. Per vastlegging wordt één e-mail verstuurd, zodra de vastlegging is gedaan.

Version control tools/Hulpmiddelen voor versiebeheer

Om toegang te krijgen tot FGAddon en het te gebruiken voor vliegtuigontwikkeling, zijn de Subversion of SVN versie control hulpmiddelen nodig. Als alternatief biedt git-svn een interface voor degenen die de voorkeur geven aan de git versie beheer systemen.

Subversion

Instellen

De FGAddon vliegtuighangar is opgeslagen in een Subversion database op de SourceForge infrastructuur en daarom is het het eenvoudigst om de SVN tools te gebruiken voor de ontwikkeling van vliegtuigen en zo de minste problemen te ontmoeten. Zie het hoofdstuk subversion installatie voor het instellen van dit gereedschap.

Repository checkout

De eerste stap is de 'checkout' van een kopie van ofwel de trunk of één van de vliegtuigen in de database:

svn co <url> <dir>

Voor het gebruik van de relevante URL moet je een van de ontwikkelscenario's kiezen en de URL in die sectie vinden. Dit betekent dat Subversion je in staat stelt om ofwel één enkel bestand uit te checken tot aan de volledige database.

Informatie en geschiedenis

Om op elk gewenst moment informatie bekijken over het lokale archief, type je:

svn info

Om de geschiedenis van de uitgecheckte kopie van de repository te zien, typ je:

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

Dagelijks gebruik

Het belangrijkste git commando dat je zult gebruiken is:

svn add <path>

Dit registreert het bestand of de map <path> binnen de lokale repository om toe te staan dat het later 'gecommit' wordt naar de lokale git repository. Als je een bestand of map wilt verplaatsen of hernoemen, gebruik je:

svn mv <path1> <path2>

Dit moet worden gebruikt in plaats van normaal verplaatsen / hernoemen van bestanden, zodat de wijziging wordt bijgehouden in de lokale repository. Als je een bestand uit de lokale repository wilt verwijderen, typ je:

svn rm <path>

Om de huidige status van het lokale archief te zien, typ je:

svn st

Als je het lokale archief wilt bijwerken met wijzigingen in het externe archief, typ je:

svn up

Veranderingen doorvoeren

Alle bovenstaande bewerkingen vinden alleen plaats in de lokale repository-kopie - de externe FGAddon-repository bij SourceForge zal niets van deze wijzigingen weten. Als je al jouw wijzigingen naar FGAddon wilt verzenden, moet je de wijzigingen doorvoeren met:

svn ci

Hiermee wordt een editor geopend waarmee je een informatief commit-logbericht kunt schrijven. Wanneer je commit, kun je het beste kleine modulaire commits maken, zodat elke commit overeenkomt met een enkel doel. Merk op dat je alleen commits kunt aanbieden aan FGAddon als je commit-toegang hebt.

Vertakken

Het concept van Subversion vertakking wordt momenteel alleen gebruikt in het FlightGear project voor het markeren van de stabiele releases. Als je echter nieuwsgierig bent naar vertakken, raadpleeg dan het hoofdstuk hoofdstuk over vertakken en samenvoegen in de Subversion handleiding en het Svnmerge.py script dat het proces aanzienlijk kan vereenvoudigen.

Git-svn

De git-svn tool is handig voor degenen die al vertrouwd zijn met het gebruik van git repositories of voor degenen die hun eigen prive vliegtuig ontwikkelruimte willen hebben. Git-svn verzorgt een brug tussen de remote FGAddon Subversion repository en een lokale git repository. Voor degenen die niet vertrouwd zijn met git; git-svn in combinatie met de git repository zijn veel ingewikkelder om te gebruiken dan het native Subversion gereedschapSubversion gereedschap.

Voor meer informatie over het gebruik van git, zie Howto: start werken met git Howto: Begin git te gebruiken. In het volgende wordt ervan uitgegaan dat slechts één enkel vliegtuig wordt opgeslagen in de lokale git repository

Instellen

Het git versie beheersysteem moet eerst worden geïnstalleerd.

Het klonen van één enkel vliegtuig

De eerste stap is het 'klonen' van een kopie van één van de vliegtuigen in het remote Subversion systeem:

git svn clone <aircraft_url>

Voor het gebruik van de relevante vliegtuig-URL moet je een van de ontwikkelscenario's kiezen en de betreffende URL. De URL is afhankelijk van jouw FGAddon commit access status. Het kloon commando zal een lokale git repository aanmaken met alleen die vliegtuigen die jou interesseren en zal de git-svn brug initialiseren.

Informatie en geschiedenis

Om op elk gewenst moment informatie bekijken over het lokale archief, typ::

git svn info
git branch -vva
git remote -v

To see the history of the checked out copy of the repository, typ je:

git log

Dagelijks gebruik

De belangrijkste git commando dat je zult gebruiken is:

git add <path>

Dit registreert het bestand of de map <pad> binnen de lokale repository om toe te staan dat het later 'gecommit' wordt naar de lokale git repository. Als je een bestand of map wilt verplaatsen of hernoemen, gebruikt je:

git mv <path1> <path2>

Merk echter op dat git geschiedenis niet zo robuust is als geschiedenis in svn. Zie de sectie FGAddon#Moving_or_renaming_files in de git-svn voor meer informatie over het uitvoeren van deze handeling. Als je een bestand uit het lokale archief wilt verwijderen, typ je:

git rm <path>

Om de huidige status van de lokale repository te zien, typ je:

git status

Wijzigingen doorvoeren

Aangezien git een gedistribueerd versiebeheersysteem is, worden wijzigingen vastgelegd in de lokale git repository.

git commit

Hiermee wordt een editor geopend waarmee je een informatief commit-logbericht kunt schrijven. De commit is lokaal en zal niet naar FGAddon worden verzonden.

Gespecialiseerde FGAddon tak

In bovenstaande voorbeelden werd slechts één tak verondersteld in de repositiry. Als interactie met een remote git repository of vertakking in de lokale git repository gewenst is, dan is een andere strategie vereist. De reden hiervoor is dat de met FGAddon gesynchroniseerde tak een lineaire historie moet behouden. Dit betekent dat alleen de gewenste veranderingen in de tak toegestaan worden.

In dit voorbeeld zullen twee takken worden aangemaakt in de lokale git repository:

• fgaddon: Deze tak zal worden gewijd aan de synchronisatie van FGAddon en zal een lineaire geschiedenis behouden.
• master: Een hoofdtak voor de ontwikkeling van vliegtuigen, die samenvoegingen en andere niet-lineaire historische operaties mogelijk maakt.

Uitgaande van newly cloned repositoryeen nieuw gekloneerde opslagplaats, maak de fgaddon met:

git branch fgaddon

En schakel over naar die tak:

git checkout fgaddon

Op deze tak kan dan de synchronisatie van FGAddon worden uitgevoerd. Om de ontwikkelingen uit de hoofdtak te halen, gebruik je cherry-picking om een sequentieel geordende lijst van commit hashes aan te brengen:

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

Om de lijst met commits te zien die naar FGAddon moeten worden gestuurd voorafgaand aan dcommitting, typ je::

git log git-svn..HEAD

En om de veranderingen als één diff te zien::

git diff git-svn..HEAD

Synchroniseren

Om de wijzigingen naar de remote FGAddon repository te sturen, moet je eerst overschakelen naar de dedicated (gespecialiseerde) fgaddon tak:

git checkout fgaddon

Zorg ervoor dat de lokale git-svn-repository up-to-date is met alle wijzigingen die zich hebben voorgedaan in FGAddon:

git svn rebase

Duw vervolgens de wijzigingen in FGAddon of dcommit met:

git svn dcommit

Tekortkomingen van git-svn

Waarschuwing  Het uitvoeren van git-svn clone van de /trunk/ of van de hele repository is niet aan te raden, omdat de volledige geschiedenis van de repository gedownload zal worden, resulting in a huge local repository, wat resulteert in een enorme lokale repository/database en een grote belasting vormt voor de open source infrastructuur van FlightGear.

Het is belangrijk om te begrijpen dat er een aantal bewerkingen zijn waarbij git-svn een tekort heeft. In veel gevallen moeten de svn-tools worden gebruikt.

Bestanden kopiëren tussen vliegtuigen

Let op  Git-svn houdt de kopieergeschiedenis van bestanden die normaal aanwezig is in een Subversion repository niet bij.

De belangrijkste daarvan is het kopiëren van content van andere FGAddon-vliegtuigen. In dit geval heb je FGAddon commit-toegang nodig en een lokale svn-kopie van de repository. Synchroniseer eerst de repositories door alle wijzigingen terug te draaien naar FGAddon: git svn dcommit </syntaxhighlight>

Kopieer het bestand vervolgens in de lokale svn repository:

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

En commit de verandering::

svn ci

Terug in de lokale git-svn repository, haal de nieuwe bestanden binnen:

git svn rebase

Door gebruik te maken van de subversion tools vermijd je dat de FGAddon repository aanzienlijk in omvang toeneemt, aangezien svn copies are cheap.

Bestanden verplaatsen of hernoemen

Let op  Git-svn onderhoudt niet altijd het bestandsverplaatsings- of hernoemingsgeschiedenisbestand dat normaal aanwezig is in een Subversion-repository.

Dit probleem komt voort uit het feit dat de svn geschiedenis robuuster is dan die van git. De commando's svn mv en git mv zijn niet gelijkwaardig. Het subversion commando slaat de verplaatsingsgeschiedenis direct op in het archief terwijl git dat niet doet (git gebruikt in plaats daarvan heuristische methoden om te proberen de geschiedenis te detecteren, na de wijziging). Het resultaat van het gebruik van git-svn is dat de verplaatsing vaak niet wordt gedetecteerd en de FGAddon geschiedenis een bestand of directory toont dat zou zijn verwijderd of zou zijn toegevoegd. Hierdoor neemt ook de omvang van de database toe, terwijl svn mv geen significante omvangstoename veroorzaakt. Als je een beter historisch record in de FGAddon-repository wilthebben en rekening wil houden met de back-end van de repository, dan is het raadzaam om tijdelijk over te schakelen naar de subversie-tools. Synchroniseer eerst de repositories:

git svn dcommit

Verplaats of hernoem het bestand vervolgens in de lokale svn-opslagplaats:

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

En commit de verandering:

svn ci

Terug in de lokale git-svn repository, haal je de veranderingen binnen met:

git svn rebase

Kopiëren van bestanden binnen één vliegtuig

Net zoals het svn mv commando de bewegingsinformatie direct in de repository opslaat, slaat svn cp de kopie-informatie op. Als je daarom een tekstbestand wilt dupliceren en wijzigen, gebruik je de native Subversion-tools in plaats van git-svn voor deze bewerking zodat de bestandsgeschiedenis permanent kan worden bewaard in de FGAddon-repository.

Subversion-eigenschappen

Let op  Git-svn ondersteunt momenteel alleen de svn:executable eigenschap, alle andere eigenschappen worden genegeerd en kunnen niet worden toegevoegd, gewijzigd of verwijderd in een git-svn-kloon van het vliegtuig.

Intern identificeert Subversion binaire bestanden met behulp van de eigenschap svn:mime-type repository. Omdat git-svn deze eigenschap echter niet kan instellen bij gebruik van het commando git add, is het resultaat dat binaire bestanden als tekst worden behandeld. Binaire diffs zullen gezien worden bij het gebruik van svn diff of git diff, en een binair diff zal getoond worden in de FGAddon commitlog mailinglijst berichten. Aangezien dit issue niet uniek is voor git-svn, kun je het beste ook nog even kijken bij binary diffs.

andere protocollen dan svn+ssh

Het commando git svn init reproduceert de volledige geschiedenis van een vliegtuig in een lokaal archief. Als onderdeel van dit proces genereert het een git commit ID of hash voor elke Subversion revisie. Het probleem is dat de git commit ID afhankelijk is van het protocol dat gebruikt wordt om te lezen uit de Subversion repository (waarschijnlijk een git bug). Vandaar dat:

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

en

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

zal resulteren in twee verschillende en incompatibele git repositories, ook al bevatten ze dezelfde gegevens. De onverenigbaarheid is niet meteen duidelijk, maar zal later problemen opleveren. Stel dat iemand met alleen-lezen toegang tot FGAddon de https-methode gebruikt en vervolgens een FGAddon admin vraagt om zijn wijzigingen vast te leggen. De admin gebruikt natuurlijk svn+ssh, aangezien dit het enige protocol is dat met schrijfrechten werkt. Wanneer de admin probeert om de https-bijdrage van de contribuant samen te voegen in de eigen svn+ssh kloon, dan zal git klagen dat de twee repositories geen geschiedenis gemeen hebben, en elke verandering als een conflict markeren.

Dus, als je van plan bent om wijzigingen aan te brengen aan de code van een vliegtuig, zorg er dan voor dat je svn+ssh gebruikt, zelfs als je nog geen commit rechten op FGAddon hebt. Voor svn+ssh zijn geen schrijfrechten vereist, maar alleen een SourceForge-gebruikers-ID.

Ontwikkelconcepten FGAddon

Nieuwe vliegtuigen

Om een nieuw vliegtuig toe te voegen aan de FGAddon repository is het SVN gereedschap nodig. Als je problemen met svn:mime-type rechten ondervindt bij het toevoegen van een nieuw vliegtuig, kijk dan bij mime-type problems sectie voor het oplossen van het probleem.

svn import

Waarschuwing  Het hierin beschreven svn import commando zal alle inhoud van de opgegeven directory direct naar FGAddon sturen zonder waarschuwing en zonder een manier om de bewerking te annuleren. Daarom moet je extra voorzichtig zijn bij het specificeren van de map die je wilt uploaden naar FGAddon, datzelfde geldt voor de doelmap binnen FGAddon. Zie de sectie svn toevoegen hieronder voor een veiligere manier om een nieuw vliegtuig toe te voegen.

De opdracht svn import is de eenvoudigste methode en je hoeft geen lokale kopie van het archief uit te checken. Om te beginnen:

1. Creëer een lege lokale vliegtuigdirectory.
2. Kopieer de vliegtuigbestanden naar deze directory
3. Controleer zorgvuldig alle bestanden om er zeker van te zijn dat er geen verborgen of tijdelijke bestanden zijn die niet naar FGAddon geüpload moeten worden.

Aangenomen dat het Dead Simple Human Powered Airplane (DaSH PA of "DaSH") vliegtuig als voorbeeld kan dienen, dat zich in de map DaSH/ bevindt, geef dan op de commandoregel de opdracht:

svn import DaSH/ svn+ssh://<username>@svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/DaSH/ -m \
    "Initial import of the DaSH human powered aircraft.\n\nFor details see the forum thread at http://forum.flightgear.org/viewtopic.php?f=4&t=24495 ."

Hierin is <usernaam> jouw SourceForge gebruikersnaam. Dit zal alle bestanden toevoegen aan FGAddon met commit log bericht met de overzichtsregel Initial import of the DaSH human powered aircraft., gevolgd door een blanco regel, en vervolgens een gedetailleerde beschrijving die verwijst naar de oorspronkelijke locatie of bespreking van het vliegtuig. Om te zien of het vliegtuig met succes is toegevoegd aan de repository, typ je:

svn list svn+ssh://<username>@svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/DaSH/

Of bezoek de {fgaddon bron|path=Aircraft|text=FGAddon web interface}}. Het vliegtuig kan dan worden uitgecheckt zoals beschreven in de #Ontwikkelingsscenario's sectie.