Nl/FGAddon

De officiële FGAddon vliegtuighangar is een versiebeheersysteem, gehost op de SourceForge infrastructure van FlightGear en wordt gebruikt voor de continue ontwikkeling van FlightGear-vliegtuigen. FGAddon is een Apache Subversion versiebeheer opslaglocatie. De vliegtuigen die hierin zijn opgenomen maken geen deel uit 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 gekoppeld aan elke stabiele release voor de FlightGear download pages.

Het FGAddon-ontwikkelcentrum 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, omdat de stabiele releases van FlightGear versie 3.4 en volgende van FlightGear worden gekoppeld aan de opbergruimte van FGAddon, kunnen de Subversion hulpmiddelen een handige manier zijn om individuele vliegtuigen of het complete aanbod van ongeveer 500 vliegtuigen te verkrijgen. Ook als je gebruik maakt van de laatste 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 had betrekking op het ontwikkelen van 2D- en 3D grafische routines voor de simulator. Dit was echter een enorme taak die begin 1997 onvoltooid 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, maar verspreid over verschillende 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-repositories . 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, namen omvang en bereik 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 weer gekoppeld aan fgdata. Deze poging was echter geen succes en werd gestopt. Vanaf deze datum tot eind 2014 werd het ontwerp van de fgdata splitsing bediscussieerd 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 wel 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 de vliegtuigen vergemakkelijken en tegelijkertijd zorgen voor modulariteit, 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, een collectie 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 gebruiken 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 onverwachte problemen ontmoeten 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 en wel 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 downloaden 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}.
  • Dit commando zou ook moeten werken voor het Raspberry Pi platform: sudo apt-get install subversion. Het bevat ook een client.

FGAddon mappenstructuur

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 de vliegtuigen.
• /branches/release-x.y.z/: Deze directories/mappen komen overeen met de verschillende 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 wel 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, en je wilt alle FGAddon-vliegtuigen downloaden voor die specifieke 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 https:// URL's en gebruik deze in de betreffende GUI (elke GUI is anders, zie de relevante documentatie voor hulp). Voor de versie van TortoiseSVN:

• Maak in Windows Verkenner een nieuwe, lege map aan voor het vliegtuig (of voor een verzameling vliegtuigen)
• 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 het commandoregelgereeedschap mee te nemen 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 kunt overslaan.

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 uit de officiële FlightGear hangar of vanuit een van de private hangars te helpen ontwikkelen en vooruit te helpen is door contact te leggen met de oorspronkelijke ontwikkelaar(s). Hun namen kun je vinden in het *-set.xml bestand en wel in de <authors> XML tag. Vaak wordt het emailadres van de ontwikkelaar vermeld in een README-bestand of in 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 ontwikkelaar(s) is belangrijk om te zien of het vliegtuig nog actief wordt doorontwikkeld en of jij als onderdeel van het ontwikkelteam mee kunt helpen.

SourceForge account

Om aan de officiële vliegtuigcollectie mee te kunnen werken, moet eerst een https://sourceforge.net/user/registration SourceForge-account worden aangemaakt. Op die manier kun je, zodra toegang is verleend, ofwel direct bijdragen leveren via de FGAddon repository of meewerken 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.

Toegang tot Commit

Voordat je toegang tot "commit" krijgt, moet je eerst alles in het werk stellen om contact op te nemen met de oorspronkelijke ontwikkelaar(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 development 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 jou als mentor 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 ontwikkelvaardigheden 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 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 Nl/FGAddon#Ontwikkelscenario's 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 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 kunnen 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 versiebeheersystemen.

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 om zo de minste problemen te ontmoeten. Zie het hoofdstuk Voorbereiding voor het instellen van deze hulpmiddelen.

Repository checkout

De eerste stap is de zogenaamde 'checkout' van een kopie van ofwel de repository trunk of één van de vliegtuigen daaruit:

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 commando maakt een lokale subversion repository kopie aan in de gegeven <dir> directory. Let op dat dit alleen het deel van de FGAddon repository bevat dat in de URL is gespecificeerd. 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 te kunnen bekijken over het lokale bestand, 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 Subversion 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 remote 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 het 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 Toegang tot Commit 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 diegenen die al vertrouwd zijn met het gebruik van git repositories of voor degenen die hun eigen privé vliegtuig ontwikkelruimte willen hebben. Git-svn verzorgt een brug tussen de remote FGAddon Subversion repository en een lokaal opgeslagen git repository. Voor degenen die niet vertrouwd zijn met git, git-svn in combinatie met de git repository is veel ingewikkelder om te gebruiken dan het native Subversion 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 vind je in dat onderdeel. De URL is afhankelijk van jouw FGAddon Toegang tot Commit. Het kloon commando zal een lokale git repository aanmaken met alleen het vliegtuig van jouw voorkeur en zal de git-svn brug initialiseren.

Informatie en geschiedenis

Om op elk gewenst moment informatie te kunnen bekijken over het lokale bestand, typ je:

git svn info
git branch -vva
git remote -v

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

git log

Dagelijks gebruik

Het 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>

Let echter op dat de git geschiedenis niet zo robuust is als geschiedenis in svn. Zie de sectie git-svn: bestanden verplaatsen of hernoemen 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 zijn we ervan uitgegaan dat er slechts één enkele versie in de repository beschikbaar is. 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 preserve a linear history moet behouden. Dit betekent dat alleen de gewenste veranderingen in die tak toegestaan worden.

In het volgende 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 een nieuw gekloonde repository maak je de nieuwe fgaddon tak met het commando:

git branch fgaddon

Schakel vervolgens 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 zullen worden gestuurd, voorafgaand aan dcommitting, typ je::

git log git-svn..HEAD

En om de veranderingen in éé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

Daarna kun je met een Push of dcommit jouw wijzigingen naar FGAddon zenden 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, 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 bewerkingen zijn waarbij het gebruik van git-svn nadelen heeft. In dergelijke gevallen verdient het aanbeveling de svn-tools te gebruiken.

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 tekortkoming betreft 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 d.m.v. dcommit terug te draaien naar FGAddon:

git svn dcommit

Kopieer het gewenste bestand vervolgens in de lokale svn repository:

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

En voer de verandering door d.m.v. commit:

svn ci

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

git svn rebase

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

Bestanden verplaatsen of hernoemen

Let op  Git-svn houdt niet altijd een overzicht bij van het verplaatsen- of hernoemen van bestanden, zoals dat wel het geval 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 de betreffende repository, terwijl git dat niet doet (git gebruikt in plaats daarvan heuristische methoden om op een later moment te proberen de geschiedenis te herleiden). Het resultaat van het gebruik van git-svn is dat de verplaatsing vaak niet wordt getoond. De FGAddon geschiedenis geeft daarentegen aan dat een bestand of directory zou zijn verwijderd, terwijl een ander zou zijn toegevoegd. Hierdoor neemt ook de omvang van de database toe. Het svn mv commando leidt daarentegen niet tot een significante toename van de omvang van de repository-backend. Als je een beter historisch overzicht in de FGAddon-repository wil hebben en rekening wil houden met de backend van de repository, dan is het raadzaam om tijdelijk over te schakelen naar de subversion tools. Synchroniseer eerst de repositories:

git svn dcommit

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

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 commando svn mv de bewegingsinformatie direct in de repository opslaat, slaat svn cp de kopieerinformatie op. Dus als je een tekstbestand wilt dupliceren en aanpassen, dan 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 repository eigenschap svn:mime-type. Omdat git-svn deze eigenschap niet kan instellen bij gebruik van het commando git add, is het resultaat dat binaire bestanden als tekst worden behandeld. Binaire diffs zullen getoond 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 Binaire verschillen .

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 op een later moment 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_add=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 een 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 web interface. Het vliegtuig kan dan worden uitgecheckt zoals beschreven in de Ontwikkelscenario's.

svn add (=toevoegen)

Als er een lokale kopie van de FGAddon-hoofdmap aanwezig is, dan kan het commando svn add in plaats daarvan worden gebruikt. Dit is veel veiliger dan het svn import commando, omdat de wijziging voor het vastleggen dubbel gecontroleerd kan worden. Maak in de map Aircraft/ van het lokale archief de map DaSH/ aan. Deze kan leeg zijn, maar kan ook alle bestanden van het initiële vliegtuig bevatten. Voeg vervolgens op de commandoregel het vliegtuig toe aan de lokale repository:

svn add DaSH/

Controleer dan eerst goed de wijzigingen voordat je e.e.a. vastlegt:

svn st

En stuur de wijzigingen naar FGAddon d.m.v.:

svn ci

Een editor, vaak vi, zal openen en de commit boodschap kan worden opgesteld. Als alternatief kan het logboekbericht worden gegeven op de opdrachtregel m.b.v.:

svn ci -m "<subject_line>\n\n<detailed_description>".

blokkeren van vastlegging door pre-commit hooks

Soms wordt bij het committen naar FGAddon de vastlegging geblokkeerd en wordt het volgende geprint:

svn: E165001: Commit mislukt (details follow):
svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output:

Dit is te wijten aan de aanwezigheid van twee repository pre-commit hook scripts die de kwaliteit van de vastlegging controleren, het blokkeren als een tekstbestand is ingesteld op een binair mime-type bestand of als de executable flag is ingesteld. Deze scripts dienen eenvoudig om de repository te beschermen en vervuiling te voorkomen.

Mime-type problemen

Soms wordt, bij een poging om bestanden vast te leggen in FGAddon met behulp van het SVN gereedschap, de vastlegging geblokkeerd met het volgende bericht:

Sending        dash-set.xml
svn: E165001: Commit failed (details follow):
svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output:

Aborting the commit, the svn:mime-type property is labelling the following text
files as binary:

  dash-set.xml:  svn:mime-type=application/xml

Before committing, please remove this property by typing 'svn propdel svn:mime-
type file_name' for all affected files.  This will allow the text files to be
treated as text within the FGAddon repository.

To avoid the svn:mime-type property being incorrectly set by your subversion
client, the subversion configuration file at $HOME/.subversion/config or
%appdata%\roaming\subversion\config should be edited and a new entry added to
[auto-props] for each affected file type.  In most cases, the problem is with
XML files being labelled as "application/xml" by a library called libmagic.  To
override this, add the following to the svn config file:

*.xml = svn:mime-type=text/xml

svn: E165001: Your commit message was left in a temporary file:
svn: E165001:    '/flightgear/repo_testing/svn-commit.tmp'

Ondanks berichten over het toevoegen of verzenden van bestanden, zal er geen verandering hebben plaatsgevonden in de FGAddon repository. Dit bericht wordt aangemaakt door een repository pre-commit hook script dat controleert of de Subversion eigenschap svn:mime-type voorkomt op een lijst van bekende tekstbestanden en, als het mime-type is ingesteld op een binair formaat, wordt de vastlegging geblokkeerd. De reden voor deze blokkade is het beschermen van de repository. Nieuwere SVN clients vertrouwen op een 3rd party library bekend als libmagic die de vliegtuig XML bestanden zal detecteren als het binaire mime-type van -application/xml. Het resultaat hiervan is dat de XML-bestanden worden behandeld als binaire bestanden in het archief. Dit gedrag is absoluut onwenselijk, omdat veranderingen hierdoor niet kunnen worden gevolgd op de flightgear-fgaddon-commitlogs mailinglijst of in de repository geschiedenis. Ook zal de grootte van de commits hierdoor vele malen groter worden. Om dit probleem te voorkomen is deze werkwijze geblokkeerd om het FlightGear project te beschermen. Als oplossing probleem, volg je de instructies in het bericht en typ je het met behulp van de opdrachtregeltools:

svn propdel svn:mime-type <file_name>

Herhaal dit voor elk tekstbestand in de foutmelding. Maak dan opnieuw een commit met behulp van het bericht dat opgeslagen is in het svn-commit.tmp bestand. De bestandsnaam van het bericht wordt gerapporteerd in het logbericht over de foutmelding, maar controleer eerst de inhoud:

cat svn-commit.tmp

En voer de commit nogmaals uit:

svn ci -F svn-commit.tmp

Subversion config file

De automatische instelling van svn:mime-type kan worden geregeld door het bestand Subversion config aan te passen. Controleer eerst in de sectie [miscellany] of de auto-eigenschappen zijn ingeschakeld:

enable-auto-props = yes

Voeg dan in het gedeelte [auto-props] toe:

*.ac = svn:mime-type=text/plain
*.eff = svn:mime-type=text/xml
*.frag = svn:mime-type=text/plain
*.nas = svn:mime-type=text/plain
*.osgx = svn:mime-type=text/xml
*.svg = svn:mime-type=text/svg+xml
*.txt = svn:mime-type=text/plain
*.vert = svn:mime-type=text/plain
*.xhtml = svn:mime-type=text/xml
*.xml = svn:mime-type=text/xml
*.xsl = svn:mime-type=text/xml

Dit zijn alle tekstbestanden waarvan het hook script zal controleren of het mime-type is ingesteld op een tekstformaat, hoewel er in de toekomst waarschijnlijk nieuwe tekstbestanden zullen worden toegevoegd. Deze aanvullingen kunnen zowel aan het gebruiker-configuratiebestand in ~/.subversion/config (of %USERPROFILE%\AppData\Roaming\Subversion\config in Windows) worden toegevoegd of, als er geen gebruiker-configuratiebestand bestaat, aan het algemene configuratiebestand op /etc/subversion/config (of %APPDATA%\Subversion\config in Windows) worden toegevoegd.

Executable flag

Een ander blokkeringsbericht bij het vastleggen van bestanden aan FGAddon met behulp van het SVN gereedschap is:

Adding         dash-set.xml
Transmitting file data .svn: E165001: Commit failed (details follow):
svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output:

The svn:executable property is set on the files ['dash-set.xml'], aborting the
commit.

The current policy is that no executable files are allowed in FGAddon.  Before
committing, please remove this property by typing 'svn propdel svn:executable
file_name' for all affected files.  Or to remove it recursively from all files
to be committed, in your aircraft directory type 'svn propdel svn:executable
-R'.

To avoid the svn:executable property being set by your subversion client, on
GNU/Linux and Mac OS X systems simply make sure that the file's execute bit is
not set before adding the file to be committed.

svn: E165001: Your commit message was left in a temporary file:
svn: E165001:    '/flightgear/repo_testing/svn-commit.tmp'

Dit zal waarschijnlijk alleen te zien zijn op Mac OS X en GNU/Linux-systemen. Dit bericht wordt afgedrukt met behulp van een script dat controleert of de Subversion eigenschap svn:executable is ingesteld en, als dit het geval is, wordt de vastlegging geblokkeerd. Dit is een veiligheidsmaatregel omdat vliegtuigbestanden niet uitvoerbaar mogen zijn. Om het probleem op te lossen, volg je de instructies in het bericht en typ je op de command line:

svn propdel svn:executable -R

Maak dan opnieuw een vastlegging met behulp van het bericht dat opgeslagen is in het svn-commit.tmp bestand. De bestandsnaam van het bericht wordt opgenomen in de foutmelding voor het vastleggen, maar controleer eerst de inhoud:

kat svn-commit.tmp

Herhaal vervolgens de vastlegging:

svn ci -F svn-commit.tmp

Binaire verschillen

Waarschuwing  De verkeerde instelling of het ontbreken van de eigenschap van het mime-type van een binair bestand zal resulteren in een binair verschil.

Als je kijkt naar de output van svn diff (of git diff als je git-svn gebruikt) of als je berichten leest van de FGAddon commitlog mailinglijst, kan het zijn dat je een groot aantal onherkenbare tekens ziet. Dit is het resultaat van wat bekend staat als een binary diff, die de binaire bestandsverschillen toont alsof het om tekst gaat. Hoewel dit geen probleem is voor het gebruik van de repository, is wel sprake van een esthetisch probleem, dat het moeilijker maakt om de wijzigingen te evalueren.

Om het probleem op te lossen moeten eerst de binaire bestanden met waarvan de eigenschap svn:mime-type ontbreekt, worden geïdentificeerd. Het volgende subversion commando kan hiertoe worden gebruikt:

svn propget svn:mime-type <file_name>

Omdat het een hele klus kan zijn om elk bestand afzonderlijk te controleren, vereenvoudigt en automatiseert het volgende Python-script het proces om alle binaire bestanden te herkennen met een probleem van het mime-type:

Python 2/3 script: Find binary files with no svn:mime-type property set.

The following script is based on blacklisting text files. Hence false positives are to be expected, and the blacklists can be expanded as needed.

#! /usr/bin/env python
from os import getcwd, walk
from os.path import join, splitext
from re import search
from subprocess import PIPE, Popen


skip_txt_file_seg = [
    'authors',
    'copying',
    'licen',
    'readme'
]

skip_txt_ext = [
    'ac',
    'css',
    'dat',
    'eff',
    'frag',
    'html',
    'json',
    'log',
    'nas',
    'osgx',
    'svg',
    'tex',
    'txt',
    'vert',
    'xhtml',
    'xml',
    'xsl'
]

skip_bin_prop = [
    'application/octet-stream',
    'application/pdf',
    'application/postscript',
    'application/x-dosexec',
    'application/x-gzip',
    'application/zip',
    'audio/x-wav',
    'image/gif',
    'image/jpeg',
    'image/png',
    'image/vnd.adobe.photoshop',
    'image/tiff',
    'image/x-ms-bmp',
    'image/x-xcf',
]

# Walk through the directories.
for root, dirs, files in walk(getcwd()):
    # Loop over the files in the current directory.
    for file in files:
        # Skip known text files.
        skip = False
        for i in range(len(skip_txt_file_seg)):
            if search(skip_txt_file_seg[i], file.lower()):
                skip = True
        if skip:
            continue

        # The file extension.
        file_path, ext = splitext(file)
        ext = ext[1:].lower()

        # Skip known text file extensions.
        if ext in skip_txt_ext:
            continue

        # The full file path.
        path = join(root, file)

        # Query the file for svn:mime-type.
        cmd = 'svn propget svn:mime-type \"%s\"' % path
        pipe = Popen(cmd, shell=True, stdin=PIPE, stdout=PIPE, stderr=PIPE, close_fds=False)
        props = []
        for line in pipe.stdout.readlines():
            props.append(line.strip())

        # Byte array conversion (Python3).
        for i in range(len(props)):
            if hasattr(props[i], 'decode'):
                props[i] = props[i].decode()

        # Skip binary svn:mime-type values.
        if len(props) and props[0] in skip_bin_prop:
            continue

        # Printout.
        if not len(props):
            print("%s" % path)
        else:
            print("%s    svn:mime-type=%s" % (path, props[0]))

het oplossen van het probleem

Aangezien Subversion-eigenschappen het svn:mime-type niet kunnen veranderen, is een svn checkout copy van het vliegtuig noodzakelijk. De eigenschap kan dan worden ingesteld op het standaard Subversion binary mime-type met:

svn propset svn:mime-type "application/octet-stream" <file_name>.

Als alternatief kunnen de volgende shellcommando's worden gebruikt om het proces te automatiseren:

Shell commands: Set specific svn:mime-type values on a set of known binary files.

These shell commands will work on GNU/Linux or Mac OS X systems (or on Windows if using cygwin, or if a find command line tool is installed). The list of file types here are those most commonly found in FGAddon. To set the property on a list of binary files, type (or copy and paste):

find -iname "*.wav" -exec svn propset svn:mime-type "audio/x-wav" {} \;
find -iname "*.bmp*" -exec svn propset svn:mime-type "image/x-ms-bmp" {} \;
find -iname "*.gif" -exec svn propset svn:mime-type "image/gif" {} \;
find -iname "*.jpg" -exec svn propset svn:mime-type "image/jpeg" {} \;
find -iname "*.png*" -exec svn propset svn:mime-type "image/png" {} \;
find -iname "*.psd" -exec svn propset svn:mime-type "image/vnd.adobe.photoshop" {} \;
find -iname "*.tif" -exec svn propset svn:mime-type "image/tiff" {} \;
find -iname "*.xcf" -exec svn propset svn:mime-type "image/x-xcf" {} \;
find -iname "*.rgb*" -exec svn propset svn:mime-type "application/octet-stream" {} \;
find -iname "*.au" -exec svn propset svn:mime-type "application/octet-stream" {} \;
find -iname "*.*af" -exec svn propset svn:mime-type "application/octet-stream" {} \;
find -iname "*.3ds" -exec svn propset svn:mime-type "application/octet-stream" {} \;
find -iname "*.blend*" -exec svn propset svn:mime-type "application/octet-stream" {} \;
find -iname "*.dds" -exec svn propset svn:mime-type "application/octet-stream" {} \;
find -iname "*.od[gst]" -exec svn propset svn:mime-type "application/octet-stream" {} \;
find -iname "*.onetoc2" -exec svn propset svn:mime-type "application/octet-stream" {} \;
find -iname "*.xlsx" -exec svn propset svn:mime-type "application/octet-stream" {} \;
find -iname "*.pdf" -exec svn propset svn:mime-type "application/pdf" {} \;
find -iname "*.ps" -exec svn propset svn:mime-type "application/postscript" {} \;
find -iname "*.gz" -exec svn propset svn:mime-type "application/x-gzip" {} \;
find -iname "*.mdl" -exec svn propset svn:mime-type "application/x-dosexec" {} \;
find -iname "*.zip" -exec svn propset svn:mime-type "application/zip" {} \;

Other binary files can safely be set to "application/octet-stream", the Subversion default for binary files.

SourceForge-ontwikkel services

Het FlightGear-project wordt gehost op de open-source-infrastructuur van SourceForge. Deze ontwikkeldienstenparagraaf zal een aantal van de nuttige tools belichten waarvan je kunt profiteren. SourceForge kent twee categorieën van diensten:

Project-infrastructuur

Het FlightGear project maakt gebruik van de projectdiensten van SourceForge. Deze diensten zijn bedoeld voor stand-alone software projecten.

Ontwikkelaars-infrastructuur

Dit zijn diensten die beschikbaar zijn voor iedereen met een SourceForge account, zij zijn beschikbaar via de SourceForge homepage en toegankelijk voor iedereen. Dit omvat de mogelijkheid om meerdere versie controle repositories (svn, git, hg), wiki's, forums, ontwikkelteams, blogs, en ticket trackers (voor bugs, supportvragen, taken, enz.) te creëren.

In plaats van steeds een nieuw project te creëren, zou iedere ontwikkeling voor het FlightGear-project gebaseerd moeten zijn op de ontwikkelaars-infrastructuur.

ontwikkelaar git repository

Om je eigen remote git repository in te richten, hier t.b.v. het ontwikkelen van het FGAddon fkdr1 vliegtuig, doe je het volgende:

• Op jouw profielpagina op https://sourceforge.net/u/<username>/profile/, ga je naar Admin -> Add New -> >Git.
• Label instellen op fkdr1 FGAddon git-svn repository.
• Stel het pad voor de code in op code-fkdr1. De code-* prefix is om dit te onderscheiden van de forum-*, wiki-* en andere directories.

De repository zal zich bevinden op https://sourceforge.net/u/<username>/code-fkdr1/ci/master/tree/.

Ontwikkelteams

Als jij en een groep vrienden als team een van de FGAddon-vliegtuigen zouden willen ontwikkelen, ervan uitgaande dat je contact hebt opgenomen met de oorspronkelijke vliegtuigontwikkelaars en het vliegtuig niet actief wordt doorontwikkeld, dan moet je eerst een SourceForge-ontwikkelteam opzetten. Er moet een teamleider worden aangesteld om dit op te zetten onder het eigen SourceForge-account. Ervan uitgaande dat jullie het "ornithopter"-vliegtuig willen ontwikkelen zijn de volgende stappen nodig:

• Ga naar Personal tools -> Admin.
• Klik op User Permissions.
• Klik aan de onderkant op Add a new group.
• Stel de naam in op ornithopter en sla op.
• Klik op Add in de groep ornithopter en voeg de namen van de SourceForge leden van jullie team toe.

Na het instellen van een private repository in het account van de teamleider, zoals hieronder beschreven, moet het ontwikkelteam worden ingesteld voor de repository.

• Ga naar de repository in jouw SourceForge-account.
• Klik op Admin - <repository name>, selecteer dan Permissions.
• In het gedeelte Write, verwijder je Developer en voeg je ornithopter toe.
• Klik op Save.

De leden van het ontwikkelteam krijgen daarmee toegang tot de private repository.

Teamcommunicatie

Om te helpen met de teamontwikkeling, maakt de SourceForge infrastructuur het mogelijk om meerdere dedicated discussion forums te creëren. Dit kan zowel binnen een SourceForge-project zijn als op de homepage van een SourceForge gebruiker. Dit stelt de teamleider in staat om een forum te creëren dat uitsluitend gewijd is aan de ontwikkeling van het betreffende vliegtuig. Voortbordurend op het voorbeeld van de ornithopter zijn de volgende stappen door de teamleider nog nodig:

• Op jouw profielpagina https://sourceforge.net/u/<username>/profile/, ga je naar Personal tools -> Admin.
• Klik in het linkermenu op de optie Tools.
• Klik op Discussion in de sectie Click to install.
• Verander bijvoorbeeld het label in Ornithopter forum en het pad naar forum-ornithopter. De forum-* prefix is om dit te onderscheiden van de code-*, wiki-* en andere directory's.
• Klik op Save.

Meer details zijn te vinden op SourceForge Discussion documentation.

Ontwikkelscenario's

Afzonderlijke ontwikkelaar

Note  Ontwikkelscenario: Je bent een individuele ontwikkelaar en gebruikt de standaard Subversion tools.

Dit is verreweg het eenvoudigste ontwikkelscenario en zou in de meeste gevallen gebruikt moeten worden. Als je gebruik maakt van de command line Subversion client, kun je een individueel vliegtuig uitchecken met:

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

Hierbij is <username> jouw SourceForge gebruikersnaam. Als alternatief kun je ook alle vliegtuigen uitchecken met:

svn co svn+ssh://<username>@svn.code.sf.net/p/flightgear/fgaddon/trunk flightgear-fgaddon

Als je geen commit-toegang hebt, typ je één van de volgende commando's:

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

Om de nieuwe lokale svn-repostory te kunnen gebruiken, zie Subversion gebruiksaanwijzingen.

Afzonderlijke ontwikkelaar (git-svn)

Note  Ontwikkelscenario: Je bent een individuele ontwikkelaar en gebruikt de git-svn tools.

Dit is gecompliceerder dan het gebruik van het native SVN gereedschap, maar kan nuttig zijn zonder FGAddon toegang, omdat er meerdere lokale commits kunnen worden verzonden naar de oorspronkelijke auteurs van het vliegtuig of naar de development mailinglijst/forum. Om het vliegtuig van jouw keuze te klonen in een nieuwe git repository, typ je:

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

Hier is <username> jouw gebruikersnaam en aircraft> is de mapnaam in het FGAddon archief. Dit is geldig ongeacht of je al dan niet commit-machtigingen hebt.

Om de nieuwe lokale git-repository te gebruiken, zie git-svn instructions en Tekortkomingen van git-svn.

Uploaden naar Sourceforge

Om de lokale ontwikkelingen te delen, kunnen de wijzigingen worden geüpload naar een remote git repository op de SourceForge infrastructuur. Hiervoor moet eerst een developer git repository worden ingesteld onder jouw SourceForge profiel. Voeg deze dan als volgt toe:

git remote add origin ssh://<username>@git.code.sf.net/u/<username>/code-<aircraft>/
lang = "sh".

En stuur de master branch waar ontwikkelingen mee te maken hebben:

git push --set-upstream origin master

De veranderingen in de nieuwe repository zullen zichtbaar worden via de web interface op https://sourceforge.net/u/<username>/code-<aircraft>/ci/master/tree/.

Externe git-repository veranderingen verzenden naar FGAddon

Note  Ontwikkelingsscenario: Jij bent een individuele ontwikkelaar met FGAddon commit toegang en je wilt de commits in een remote git repository overzetten naar FGAddon met behulp van een tijdelijke, lokale git repository.

Kloon eerst het FGAddon vliegtuig in een lokale git-svn repository d.m.v.:

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

Hierdoor ontstaat een nieuwe lokale git repository gekoppeld aan FGAddon via git-svn. Als het vliegtuig nieuw is en niet aanwezig in FGAddon, kijk dan bij instructies voor het toevoegen van nieuwe vliegtuigen aan FGAddon. Stel vervolgens de remote git repository in als remote, en haal de gegevens op met:

git remote add <name> <url>
git fetch

<url> is hierbij de URL is van het remote git archief. Maak ten slotte een geordende lijst van alle hashes van de commits die allemaal naar FGAddon gestuurd moeten worden, en cherry-pick ze in de git-svn hoofdtak:

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

Merk op dat het lokale git-svn archief slechts één master tak mag hebben en alleen betrekking heeft op cherry-picking. Om de wijzigingen te zien die in de wachtrij staan voor verzending naar FGAddon:

git log git-svn..HEAD
git diff git-svn..HEAD

Om de wijzigingen vervolgens naar FGAddon te sturen, "pull" de wijzigingen en verzendt de commits:

git svn rebase
git svn dcommit

Het tijdelijke lokale archief kan vervolgens worden verwijderd.

Een bestaande git-repository verbinden met FGAddon

Note  Ontwikkelscenario: Je bent een individuele ontwikkelaar of teamleider met FGAddon commit toegang en je wilt een reeds bestaande remote git repository verbinden met FGAddon om alle wijzigingen terug te sturen naar FGAddon.

Als er al een remote git repository bestaat met een ontwikkeld vliegtuig, is het mogelijk om deze te koppelen aan de remote FGAddon repository met behulp van de git-svn tools.

Het volgende voorbeeld maakt gebruik van de Gespecialiseerde FGAddon tak. Om te beginnen maak je de koppeling naar FGAddon met behulp van git-svn in de vliegtuigspecifieke repository:

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

Hierin is <aircraft> de naam van de vliegtuigdirectory in FGAddon. Merk op dat deze stap kan worden uitgevoerd zonder commit-toegang tot FGAddon door gebruik van een alleen-lezen SVN URL, maar dat wijzigingen vervolgens niet kunnen worden gerealiseerd in FGAddon dcommitting, zoals het in de git-svn terminologie wordt genoemd). Hierdoor kunnen upstream FGAddon-wijzigingen worden geïntegreerd in de remote git-repository, waardoor het eenvoudig wordt om wijzigingen voor te bereiden voor invoeging in FGAddon, met behulp van patches die naar de mailinglijst worden verzonden of die via andere kanalen worden verzonden.

Haal nu de huidige status op uit de externe FGAddon-repository:

git svn fetch

De gedownloade SVN-geschiedenis kun je vinden in remotes/git-svn. Om wijzigingen vast te leggen in SVN heb je een lokale tak nodig die je in staat stelt deze externe tak te volgen. Creëer een lokale fgaddon tak die je zult gebruiken om updates naar FGAddon te zenden:

git branch fgaddon remots/git-svn

Na het vastleggen van de nieuwe gegevens in de master tak en om te kunnen uploaden naar FGAddon, checkout de fgaddon tak en update via SVN in het geval iemand anders het vliegtuig heeft bewerkt in de externe FGAddon repository:

git checkout fgaddon
git svn rebase

Cherry-pick de nieuwe commits van master naar fgaddon om een lineaire geschiedenis te realiseren:

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

Om de wijzigingen te kunnen zien die in de wachtrij staan voor verzending naar FGAddon als vastlegging of als diff, typ je:

git log git-svn..HEAD
git diff git-svn..HEAD

Als alles in orde lijkt, dcommit de lokale commits op de fgaddon tak om deze aansluitend te verzenden naar de externe FGAddon SVN repository:

git svn dcommit

Schakel terug naar de master branch voor lokale ontwikkeling:

git checkout master

Om veranderingen van upstream te krijgen kunt je ze zowel gewoon downloaden met

git svn fetch

of download ze en herbouw gelijktijdig jouw fgaddon tak :

git checkout fgaddon
git svn rebase

Teamontwikkeling

Note  Ontwikkelscenario: Alle leden van het team treden op als poortwachter en alle commits worden rechtstreeks vastgelegd in FGAddon, hetzij met behulp van svn of met git-svn.

De eenvoudigste manier om als team te werken is die waarbij elke ontwikkelaar ofwel een svn kopie van FGAddon heeft ofwel een git-svn kopie van FGAddon en iedereen wijzigingen direct vastlegt in FGAddon. Communicatie en coördinatie tussen de teamleden kan worden geregeld met behulp van een door de teamleider ingesteld SourceForge forum of met behulp van het FlightGear forum. In dit scenario moet het team het initiatief nemen en vraagt iedereen toegang tot FGAddon.

Private teamontwikkeling (git-svn)

Note  Ontwikkelscenario: Een teamleider treedt op als poortwachter op een private git repository, gehost op de interne SourceForge infrastructuur, met gebruikmaking van git-svn om een fgaddon branch naar FGAddon te pushen, waarbij teamleden direct wijzigingen vastleggen in de private git repository of samenvoegverzoeken doen vanaf hun "vork" van de private repository.

Om alles in eigen huis te houden, zal de hele operatie gebaseerd zijn op de officiële infrastructuur en remote repositories onder het SourceForge (SF) profiel van elke gebruiker. Opmerking aan de teamleider - je moet keep your git-svn history lineair (wat betekent dat er een Gespecialiseerde FGAddon tak aangemaakt moet worden en dat wijzigingen manueel <<cherry-pick>> moeten worden verwerkt in deze branch). Hieronder wordt het ornithopter vliegtuig als voorbeeld gebruikt.

Het team

Om te beginnen moet het hele team zich aanmelden voor SourceForge accounts.

Teamleider

Inrichting van een privé-repository

Deze stappen moeten worden genomen door de teamleider. Stel in jouw SourceForge gebruikersprofiel een ontwikkelaar git repository in met het label Ornithopter FGAddon git-svn repository en het codepad code-ornithopter. Maak dan een lege lokale git repository:

$ mkdir ornithopter
$ cd ornithopter
$ git init

Koppel het lege archief aan de ornithopter vliegtuigdirectory in het externe FGAddon archief en download de gegevens met:

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

Vervang <<username> door jouw SF-gebruikersnaam. Zet een speciale git-svn branch op voor de koppeling met FGAddon en voor dcommitting van wijzigingen naar FGAddon:

$ git branch fgaddon remotes/git-svn
$ git checkout fgaddon

En download de ornithopter vanuit FGAddon:

$ git svn rebase

Om de huidige instelling van de lokale git-svn repository te zien, typ je:

$ git branch -vva
$ git remote -v
$ git svn info

Ga dan terug naar de hoofdtak:

$ git checkout master

Tot slot stel je de externe git repository in als remote:

$ git remote add origin ssh://<username>@git.code.sf.net/u/<username>/code-ornithopter/

En stuur de master branch naar de externe git repository:

$ git push -u origin master

Om de nieuwe opzet te zien, typ je:

$ git branch -vva
$ git remote -v

De repository zal zich bevinden op https://sourceforge.net/u/<username>/code-ornithopter/ci/master/tree/ Merk op dat de git-svn informatie die is opgeslagen in de .git/svn directory niet geűpload zal worden naar de remote SoureForge repository en daarom zal de link naar FGAddon alleen aanwezig zijn in de lokale kopie van de teamleider. De git-svn-verbinding kan, indien nodig, op een later tijdstip worden ingesteld.

Teamopstelling

Oprichting van een speciaal Ontwikkelteam met toegang tot de git-svn repository.

Uploaden naar FGAddon

Wijzigingen vastleggen in FGAddon wordt gedaan vanuit de lokale git repository van de teamleider. De geschiedenis moet lineair zijn in de tak van de fgaddon, dus cherry-picking is de juiste weg. Dit wat betreft de Afzonderlijke ontwikkelaar (git-svn) sectie. In de lokale git repository, schakel je over naar de fgaddon tak:

git checkout fgaddon

Download de wijzigingen die in FGAddon hebben plaatsgevonden:

git svn rebase

Om de wijzigingen te zien in de master tak die niet in de fgaddon tak zitten, typ je één van de volgende regels:

git log HEAD..master
git log HEAD..master --pretty=oneline

Selecteer handmatig de commits die naar FGAddon moet worden gestuurd en selecteer deze d.m.v. cherry-pick:

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

Je kunt ook d.m.v. cherry-pick een reeks commits kiezen:

git cherry-pick <commit hash 1>^..<commit hash 8>

Controleer dan wat er verstuurd gaat worden:

git log git-svn..HEAD
git diff git-svn..HEAD

Stuur de wijzigingen naar FGAddon, stuur de git fgaddon branch wijzigingen naar de externe git repository en schakel terug naar de master branch:

git svn dcommit
git push
git checkout master

Voeg tenslotte de wijzigingen samen in de git svn met hun nieuwe hashes van de fgaddon tak en stuur alles naar de remote git repository:

git merge fgaddon
git push

Teamleden

Werken met de repository

Elk teamlid zou een kloon van de private git repository moeten maken:

$ git clone ssh://<username>@git.code.sf.net/u/<username_leader>/code-ornithopter/ ornithopter

Vervang <username> door jouw SourceForge gebruikersnaam en <username_leader> is de SourceForge gebruikersnaam van de teamleider.

Verzoeken om afsplistingen en samenvoegingen

Als alternatief kan elk teamlid een afsplitsing maken van de git repository onder het SourceForge-account: Ga naar {{#tag:span|{#tag:tt|https://sourceforge.net/u/<username>/code-ornithopter/ci/meester/tree/}, waarbij <username> de SourceForge gebruikersnaam is van de teamleider.

• Click on Fork.
• Stel het pad in naar code-ornithopter en wijzig het label naar wens.

Ontwikkel en upload naar jouw afsplitsing, verzoek dan om de commits samen te voegen door te klikken op de Request Merge knop.