Nl/FGAddon

From FlightGear wiki
Jump to: navigation, search
This article is currently being translated.
Kees (talk) 08:06, 29 January 2018 (EST)
FGAddon logo.png

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.

Contents

Geschiedenis

Original Win95 icon

Het FlightGear project werd op 8 april 1996 bedacht door David Murr, die een nieuwe vluchtsimulator voorstelde die geheel door vrijwiligers zou worden ontwikkeld.[1][2][3][4]. 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. [5]. 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 [6]. 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 [7]. 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 [8]. 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.
Caution  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

Warning  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

Caution  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

Caution  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

Caution  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

Warning  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.

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 of alle bestanden van het initiële vliegtuig bevatten. Voeg vervolgens op de commandoregel het vliegtuig toe aan de lokale repository:

svn toevoegen DaSH/

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

svnstern

En stuur de wijzigingen naar FGAddon:

svn ci

Een editor, vaak vi[9], zal openen en de commit boodschap kan worden opgesteld. Als alternatief kan het logboekbestand worden gegeven op de opdrachtregel met:

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

blokkeren van vastlegging door vooraf vastgelegde haken

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

svn: E165001: Commit mislukt (details volgen):
svn: E165001: Commit geblokkeerd door pre-vastlegging haak (uitgang code 1) met 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 bestand mime-type of als de executable flag is ingesteld. Deze scripts dienen eenvoudig om de repository te beschermen en vervuiling/besmetting 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 svn:mime-type eigenschap is ingesteld op een lijst van bekende tekstbestanden en, als het mime-type is ingesteld op een binaire indeling, 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 -applicatie/xml. Het resultaat is dat de XML-bestanden worden behandeld als binaire bestanden in het archief. Dit gedrag is volstrekt onwenselijk, aangezien veranderingen niet kunnen worden gevolgd op de flightgear-fgaddon-commitlogs mailinglijst of in de repository geschiedenis, en de grootte van de commits vele malen groter worden. Daarom is deze handelwijze geblokkeerd voor de bescherming van het FlightGear project. Om het probleem op te lossen, 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:

kat 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 te wijzigen. 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 aan het gebruikersconfiguratiebestand op ~/.subversion/config (of %USERPROFILE%\AppData\Roaming\Subversion\config in Windows) of, als er geen gebruikersconfiguratiebestand is ingesteld, 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 svn:executable eigenschap is ingesteld en, indien dit het geval is, wordt de vastlegging geblokkeerd. Dit is een veiligheidsmaatregel, aangezien vliegtuigbestanden niet uitvoerbaar mogen zijn. Om het probleem op te lossen, volg je de instructies in het bericht en typ je op de commandline:

svn propdel svn:uitvoerbaar -R

Maak dan opnieuw een vastlegging met behulp van het vastleg bericht dat opgeslagen is in het svn-commit.tmp bestand. De bestandsnaam van het bericht wordt gerapporteerd 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

Warning  De verkeerde instelling of het ontbreken van de eigenschap van het mime-type op 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) en 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 binaire diff, die de binaire bestandsverschillen toont alsof het tekst was. Hoewel dit geen probleem is voor het gebruik van de repository, is de situatie een esthetisch probleem dat het moeilijker maakt om de wijzigingen te evalueren.

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

svn propget svn:mime-type <file_name>

Omdat het lastig 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:

het oplossen van het probleem

Aangezien [[#Subversion_properties|git-svn] de svn:mime-type eigenschap niet kan instellen of wijzigen, is een [[#Repository_checkout|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 "applicatie/octet-stream" <file_name>.

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

SourceForge-ontwikkelaar services

Het FlightGear-project wordt gehost op de open-source-infrastructuur van SourceForge. Deze ontwikkelaar diensten paragraaf 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.
Infrastructuur ontwikkelaars 
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, ontwikkelingsteams, blogs, en ticket trackers (voor bugs, supportaanvragen, taken, enz.) te creëren.

In plaats van steeds een nieuw project te creëren, zou elke 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 voor het ontwikkelen van de FGAddon fkdr1 vliegtuig, doe je het volgende:

Op je profiel pagina op https://sourceforge.net/u/<username>/profile/, ga je naar Admin -> Nieuw -> >Git. Label instellen op fkdr1 FGAddon git-svn repository. Stel het codepad 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/.

Ontwikkelaarteams

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 ontwikkeling verder wordt ontwikkelt, 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 wilt ontwikkelen, zijn de volgende stappen:

  • Ga naar Personal tools -> Admin.
  • Klik op User Permissions.
  • Klik op Add a new group aan de onderkant.
  • 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 onder je SourceForge-account. Klik op Admin - <repository name>, selecteer dan Permissies. 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 teamontwikkeling, maakt de SourceForge infrastructuur het mogelijk om meerdere dedicated discussion forums te creëren. Dit kan zowel binnen een SourceForge-project zijn als onder 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 je profiel pagina https://sourceforge.net/u/<username>/profile/, ga je naar Personal tools -> Admin. Klik in het linkermenu op de optie Tools. Klik op Discussie in de sectie Klik om te installeren. Verander het label in Ornithopter forum, en het pad naar forum-ornithopter, bijvoorbeeld. 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 ontwikkelingsscenario en zou in de meeste gevallen gebruikt moeten worden. Als je gebruik maakt van de commandline 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 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 instructions.

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 <vliegtuigen> 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 its deficiencies.

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:

{sourceforge url

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 user=<username>}

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 een nieuw vliegtuig aan FGAddon. Stel vervolgens de remote git repository als remote, en haal de gegevens op met:

git remote add <name> <url>
gitfetch

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

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

Merk op dat het git-svn lokale 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:

gitzvn-respons
git svn dcommit

Het tijdelijke lokale archief kan dan worden verwijderd.

Een bestaande git-repository verbinden met FGAddon

Note  Ontwikkelingsscenario: 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 aan te sluiten op het remote FGAddon repository met behulp van de git-svn tools.

Het volgende voorbeeld maakt gebruik van de dedicated FGAddon branch technique. In de eerste plaats installeer je de koppeling naar FGAddon met git-svn in de vliegtuigspecifieke repository:

{fgaddon bron

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

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

git svn fetch

De gedownloade SVN-geschiedenis bevindt zich in de externe tak remotes/git-svn. Om wijzigingen vast te leggen in SVN heb je een lokale tak nodig die deze externe tak volgt. Creëer een lokale fgaddon tak die je zult gebruiken om updates vast te leggen:

git branch fgaddon remots/git-svn

Na het vastleggen van de nieuwe gegevens in master branch, to push to FGAddon checkout the fgaddon tak en het updaten van 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 tot fgaddon om een lineaire geschiedenis te bewaren:

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

Om de wijzigingen te 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 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 gewoon downloaden met

git svn fetch

of download ze en herhaal uw fgaddon branche:

git checkout fgaddon
git svn rebase

Teamontwikkeling

Note  Ontwikkelingsscenario: Alle leden van het team treden op als gatekeepers, en alle commits worden rechtstreeks vastgelegdin FGAddon, hetzij met behulp van svn of met git-svn.

De eenvoudigste manier om als team te werken is voor elke ontwikkelaar om ofwel een svn copy of FGAddon ofwel een [[#Individual developer (git-svn)|git-svn copy of FGAddon] te hebben, en iedereen legt wijzigingen direct vast in FGAddon. Communicatie en coördinatie tussen de teamleden kan worden uitgevoerd met behulp van een team leader organised SourceForge forum of met behulp van het FlightGear forum. In dit scenario moet het team het initiatief nemen en iedereen vraagt FGAddon toegang aan.

Private teamontwikkeling (git-svn)

Note  Ontwikkelingsscenario: 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 duwen, waarbij teamleden direct wijzigingen vastleggen in de private git repository of samenvoegverzoeken doen vanaf hun "vork" van de private repository.

Om alles in 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 dedicated FGAddon branch aangemaakt moet worden en dat wijzigingen manueel 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

Privé-repository setup

Deze stappen moeten worden genomen door de teamleider. Stel in jouw SourceForge gebruikersprofiel een [[#Developer_git_repository| git repository] in met het label Ornithopter FGAddon git-svn repository en 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 FGAddon gatekeeping en het terugzetten van wijzigingen in de repository:

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

En download de ornithopter van FGAddon:

$ git svn rebase

Om de huidige instelling van de lokale git-svn 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 remote 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 remote git repository:

$ git push -u origin master

Om de nieuwe opzet te zien:

$ git branch -vva
$ git remote -v

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

Teamopstelling

Oprichting van een dedicated development team and grant them access to the git-svn repository.

Uploaden naar FGAddon

Wijzigingen vastleggen in FGAddon is voor 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 Individual developer (git-svn) sectie. In de lokale git repository, schakel over naar de fgaddon tak:

git checkout fgaddon

Download 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 één van de volgende regels:

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

Selecteer handmatig de wijzigingen die naar FGAddon moet worden gestuurd en selecteer deze:

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

Je kunt een reeks wijzigingen kiezen:

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

Controleer dan wat er verstuurd moet worden:

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

Stuur de wijzigingen naar FGAddon, stuur de git fgaddon branch wijzigingen naar de remote 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 jouw SourceForge-account: Ga naar {{#tag:span|{#tag:tt|{<nowiki source>[https://sourceforge.net/u/<username>/code-ornithopter/ci/meester/tree/ <username>/code-ornithopter/meester]</nowiki source>, waarbij <username> de SourceForge gebruikersnaam is van de teamleider.

  • Click on Fork.
  • Set the mount point to code-ornithopter and change the label as you wish.

Ontwikkel en upload naar jouw afsplitsing, voer dan de wijzigingen door door te klikken op de Request Merge knop.

References

  1. David Murr (Apr 9, 1996). FlightGear proposal 1.0: "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@". Published on the rec.aviation.simulators newsgroup.
  2. David Murr (1996). FlightGear proposal 2.0: FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0.
  3. David Murr (Oct 29, 1996). FlightGear proposal 3.0: FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here". Published on the flight-gear@infoplane.com mailing list.
  4. David Murr (Sep 11, 1998). FlightGear proposal 3.0.1: FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here".
  5. Curtis Olson (Sep 28, 2015). Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@. Published on the FlightGear forum.
  6. James Turner (May 20, 2010). [Flightgear-devel] Re: Flightgear git repositories (was Re: GIT or CVS - Confusion) Published on the flightgear-devel mailing list.
  7. Cedric Sodhi (Oct 18, 2011) [Flightgear-devel] FGData Split Completed - a.k.a Life after the Split Published on the flightgear-devel mailing list.
  8. FlightGear Policy Document and Roadmap, draft document.
  9. Vim documentatie