Fr/FGAddon

From FlightGear wiki
Jump to navigation Jump to search
FGAddon logo.png

Le hangar d'aéronef officiel FGAddon est un dépôt de gestion de versions, hébergé sur l'infrastructure de FlightGear à SourceForge, et utilisé pour le développement quotidien de l'aéronef de FlightGear. FGAddon est un dépôt de gestion de versions de Apache Subversion. Ce sont des aéronefs qui ne font pas partie du logiciel de base (les aéronefs de base — le Cessna 172P et l'UFO — se trouvent dans le dépôt FGData) mais ils sont étiquetés avec chaque version stable pour les pages de téléchargement de FlightGear.

Le dépôt de développement d'aéronef FGAddon devrait être considéré comme instable. En cas d'utilisation une version FlightGear stable, il est préférable d'obtenir un aéronef avec un numéro de version correspondant directement des pages de téléchargement de FlightGear. Cependant, comme les versions stables dès FlightGear 3.4 sont étiquetées et présentes dans le dépôt FGAddon, les outils de Subversion peuvent être un moyen pratique pour obtenir un aéronef particulier ou l'ensemble d'environ 500 aéronefs du hangar officielle. Aussi, en cas d'utilisation de la dernière version de nuit ou un version compilé de FlightGear à partir des dépôts de gestion de versions Git de FlightGear, l'utilisation de FGAddon permet aux aéronefs d'être actualisés à la dernière version de développement.


Histoire

Icône originale de Win95

Le projet FlightGear a été conçu le 8 Avril, 1996 par David Murr qui a proposé un nouveau simulateur de vol qui sera développé par des volontaires[1][2][3][4]. Une partie des objectifs initiaux était de développer des routines graphiques 2D et 3D pour le simulateur. Mais au début de 1997, cette tâche énorme est venue à un arrêt inachevé car le développeur principal, Eric Korpela, rédigeait sa thèse de doctorat. À ce point, Curtis Olson a relancé le développement le 16 mai 1997 avec un nouveau projet basé sur les bibliothèques graphique OpenGL, permettant de mettre en place un simulateur de vol fonctionnel en peu de temps[5]. Les premières commits étaient aux dépôts de gestion de versions CVS originaux de flightgear et simgear.

Pendant la croissance du projet, la taille, quantité et qualité des ressources de FlightGear a augmenté ainsi. Ces ressources n'étaient pas organisées et étaient dispersées à travers de différents lieux sur l'Internet. Par conséquent, il a été décidé qu'une grande partie de ce contenu de FlightGear serait assemblée et conservée dans un nouveau dépôt CVS centralisé appelé fgdata, créé le 22 Octobre 2000. Pour permettre la redistribution légal de ces contenus dans le cadre de la distribution FlightGear, une politique d'exclusivité de GPLv2 a été adoptée.

En mai 2010, le développement a été interrompu par «l'incident du café» infâme résultant en la retraite du serveur à domicile de Curtis qui abritait tous les dépôts de gestion de versions de FlightGear[6]. Ces événements ont entraînés une migration de masse de tous les dépôts CVS vers des dépôts Git. En raison de problèmes de bande passante, il a été décidé que les nouveaux dépôts seraient hébergés sur l'infrastructure open source de Gitorious.

En même temps que le projet a grandi, la taille et l'étendue du dépôt de fgdata a élargi lorsqu'une division était inévitable. Une première tentative de séparation a été organisée par Gijs de Rooy et annoncée le 18 Octobre, 2011[7]. Chaque aéronef a été placé dans son propre dépôt Git et tous les aéronefs lié à un nouveau dépôt fgdata-new en utilisant un démarche «Git submodule». Cependant, cette tentative n'a pas fonctionné comme prévu et a été abandonnée. À partir de cette date jusqu'à la fin de 2014, la conception de la séparation de fgdata a été discutée sur la liste de diffusion de développement et résumée dans l'article de wiki FlightGear Git: splitting fgdata. Dans les étapes de planification, les dépôts étaient nommés comme la division de fgdata-old en FGData (aussi appelé fgdata-new) et FGAddon (aussi appelé flightgear-aircraft et fgaircraft). Après une demi-décennie de planification, il a été décidé que la meilleure solution pour le développement d'aéronef FlightGear serait un seul dépôt de Subversion centralisé. Cela faciliterait la gestion par la communauté et l'entretien de l'aéronef tout en fournissant en même temps la modularité, des téléchargements plus petits et un dépôt local de taille beaucoup plus réduite.

À la fin de 2014, Gitorious, le fournisseur de l'infrastructure open source pour les dépôts de code source et ressources de FlightGear a annoncé qu'il allait fermer ses services en mai 2015 en raison de son acquisition par GitLab. Cela a catalysé la scission de fgdata-old et un déménagement à l'infrastructure open source SourceForge pour l'hébergement des dépôts de gestion de version. D'autres parties de l'infrastructure FlightGear été déjà hébergées par SourceForge, ainsi ce déménagement était un choix naturel. Pour conclure l'affaire, SourceForge a accepté par écrit d'accueillir l'immense collection d'aéronefs de FlightGear, dont la taille est inégalée dans les cercles open source. Aujourd'hui, le dépôt de SVN FGAddon, avec la plupart de l'infrastructure du projet FlightGear, est hébergé sur SourceForge.

En Août 2015, un nouveau document de politique FlightGear a été écrit pour codifier les normes non écrites du projet[8]. Avec ce document, la politique de licence pour l'aéronef de FlightGear a été actualisée d'être exclusivement GPLv2 à une position de GPLv2+ ou licence compatible[9]. Néanmoins, pour lutter contre les complications de la prolifération de licence pour l'intégrité et le bien du projet FlightGear, il est vivement recommandé que le contenu original soit sous la GPLv2+.

Obtenir les aéronefs

Conseil  Si vous souhaitez obtenir des aéronefs pour un version stable de FlightGear et vous n'êtes pas au courant avec les systèmes de gestion de versions, vous devriez visiter les hangars d'aéronefs FlightGear pour les télécharger.
Attention  Veuillez noter que si les versions de FlightGear et d'aéronef de FGAddon ne correspondent pas, des bogues étranges devraient être attendus et la mauvaise combinaison ne sera pas soutenue par la communauté de FlightGear.

Avec les outils de Subversion (SVN), le dépôt de gestion de versions FGAddon peut être un moyen commode pour obtenir les aéronefs directement de la source officielle pour utiliser avec une version spécifique de FlightGear. En utilisant la dernière version de nuit ou une copie compilé des dépôts FlightGear, la version de développement plus récente de l'aéronef doit être utilisés afin que tous les versions correspondent. Les sections suivantes décrit comment utiliser le dépôt officiel pour obtenir des avions et d'autres aéronefs au point de vue d'un utilisateur de FlightGear.

Préparation

Pour utiliser le dépôt FGAddon, les outils de Subversion doivent être installés:

  • MS Windows: Installez l'un des nombreux clients Subversion. Par exemple SlikSVN est l'un des meilleurs versions sur la ligne de commande et l'un des meilleurs pour le développement d’aéronef, et TortoiseSVN fournit un interface utilisateur graphique conviviale (GUI) en intégrant au cœur de Windows Explorer.
  • Mac OS X: Installez le client officiel de Subversion.
  • GNU/Linux: Installez le client de Subversion avec le gestionnaire de paquets. Ce sera généralement dans un paquet nommé subversion-*.{rpm,deb}.
    • Cette commende devrait fonctionner pour la platforme Raspberry Pi: sudo apt-get install subversion. Elle fournit également le client.

Structure du dépôt FGAddon

Pour savoir comment utiliser le dépôt FGAddon, une compréhension de la structure des répertoires du dépôt est essentielle.

  • /trunk: Ce dossier de base est où se trouvent les versions d’aéronef en développement.
  • /branches/release-x.y.z/: Ces dossiers correspondent aux versions stables de FlightGear.

L'interface web pour le dépôt FGAddon permet de parcourir tous les aéronefs.

Téléchargement

Aéronef à télécharger

En premier lieu, un aéronef à télécharger devrait être choisi. Le Bell Boeing V-22 Osprey sera utilisé dans cet exemple.

Ligne de commande

Pour télécharger l'aéronef pour FlightGear 3.4, il suffit de taper: 

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

Pour obtenir la version en développement, tapez: 

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

Si tous les environ 500 aéronefs du dépôt sont souhaités - faites attention que ce sera un énorme téléchargement de plus de 6 Go - utilisez la commande suivante: 

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

En cas d'utilisation une version FlightGear stable, par exemple FlightGear 2016.1, pour obtenir tous les aéronefs de FGAddon qui correspondent à la version de FlightGear installée, utilise: 

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

Clients GUI et TortoiseSVN

Lors de l'utilisation d'un des GUI de Subversion (interfaces utilisateur graphiques), il suffit de copier l'un des URLs https:// et de l'utiliser dans l'interface graphique (chaque GUI est différent, alors consultez la documentation correspondant). Pour l'outil unique TortoiseSVN, il faut tout simplement:

  • Dans Windows Explorer, créez un nouveau dossier vide pour l'aéronef (ou la collection complète d'aéronef).
  • Dans le nouveau dossier, cliquez avec le bouton de droit et sélectionnez SVN Checkout....
  • Copiez-collez le URL, par exemple https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/V22-Osprey, laissez tous les autres paramètres tels qu'ils sont, et importez en cliquant sur OK.

Pour tous les détails, consultez la documentation de TortoiseSVN. Notez qu'il ya une option pour installer les outils de ligne de commande lors de l'installation de TortoiseSVN.

Voler

Pour utiliser l'aéronef nouvellement téléchargé, voyez l'article Howto:Installer un avion, et sautez les instructions pour le téléchargement et la décompression de l'aéronef.

Mettre à jour

Avec une copie extraite de la version en développement de /trunk, l’aéronef peut être mis à jour en utilisant la commande: 

svn up

Développement d'aéronef

Conseil  La communauté FlightGear encourage le développement d'aéronef directement au sein de FGAddon.

Contactez les auteurs de l'aéronef

La première étape pour le développement et l'avancement d'un aéronef dans le hangar officielle de FlightGear, d'ailleurs aussi dans l'un des hangars privés, est d'établir contact avec l'auteur ou les auteurs originaux de l'aéronef. Leurs noms peuvent être trouvés dans le fichier *-set.xml, dans la balise XML <auteurs>. Souvent les adresses email des auteurs sera listées dans un fichier README ou un autre fichier de texte dans le répertoire de base de l'aéronef. Si non, un contact peut parfois être établie sur la liste de diffusion de développement FlightGear. Contact avec les auteurs originaux est important pour savoir si l'aéronef est en développement actif, et si vous pouvez participer dans l'équipe de développement.

Compte SourceForge

Pour modifier et d'améliorer la collection officielle d'aéronef, un compte SourceForge doit être enregistré. Cela permettra soit de faire un commit directement au dépôt FGAddon, si l'accès commit a été accordé, ou de travailler dans le cadre d'une équipe de développement à SourceForge. Le processus d'inscription est très rapide et l'infrastructure de développeur et les services de développement à SourceForge sera accessible en moins d'une minute.

Accès commit

Avant d'obtenir l'accès commit, tous les efforts nécessaires doit être faite pour contacter l'auteur original pour déterminer si l’aéronef est en développement actif. Si cela ne fonctionne pas, inscrivez-vous à la liste de diffusion de développement FlightGear et demandez de l'aide sur la liste. Si l'aéronef a un responsable actuel, vous serez dirigé sur la façon de procéder avec les développements. Sinon, demandez si quelqu'un pourrait servir de mentor bénévole dans le processus de devenir un développeur d'aéronef avec un accès commit complet.

Pour obtenir l'accès commit, vous devrez d'abord:

  1. Démontrer votre capacité et compétence dans le développement.
  2. Montrer que vous comprenez le document de politique de FlightGear.
  3. Montrer une bonne compréhension des questions de licence GPL, et qu'on peut vous faire confiance de ne pas utiliser du matériel non-GPL protégé par le droit d'auteur.
  4. Gagner la confiance de la communauté FlightGear.

Ces facile à surmonter obstacles sont tout simplement conçu pour la protection du dépôt contre la corruption ou contre la pollution avec un contenu illégal.

Pour avoir vos modifications ajoutés dans le dépôt FGAddon, vous devriez discuter et coordonner avec l'auteur original de l'aéronef, ou votre mentor, de la meilleure façon de procéder. Selon le scénario de développement, cela peut-être par un «merge request», un transfert de fichiers, le système primitive de patch, ou par n'importe quel façon pratique. Lorsque vous croyez que vous avez démontré vos capacités et que vous être bien informé sur les questions de licence GPL, vous devriez écrire un email à la liste de diffusion de développement et demandez si vous pouvez obtenir l'accès commit, en fournissant votre nom d'utilisateur de SourceForge.

Liste de diffusion FGAddon commitlogs

Pour suivre tout changements dans le dépôt FGAddon, abonnez-vous à la liste de diffusion flightgear-fgaddon-commitlogs. Un email est envoyé pour chaque commit, dès que la validation est faite.

Outils de gestion de versions

Pour avoir accès à FGAddon et de l'utiliser pour le développement de l'aéronef, les outils de gestion de versions Subversion ou SVN sont nécessaires. Une autre solution consiste à utiliser git-svn, un outil qui fournit une interface pour ceux qui préfèrent les gestion de versions Git.

Subversion

Mettre en place

Le hangar d'aéronef FGAddon est maintenu dans un dépôt Subversion distant situé sur l'infrastructure SourceForge. D'utiliser les outils de SVN pour le développement de l'aéronef est donc le moyen le plus simple et qui amène le moins de problèmes. Consultez la section d'installation de Subversion pour la mise en place de la chaîne d'outil.

Checkout du dépôt

La première étape consiste de faire un «checkout» (en français appelé une extraction) pour obtenir une copie soit du trunk du dépôt ou l'un des aéronefs dans le trunk: 

svn co <url> <dir>

Pour l’adresse URL pertinente, vous devriez choisir l'un des scénarios de développement et trouvez l'URL dans la section correspondante. Cette commande créera un dépôt Subversion local dans le dossier <dir> fourni. Viellez noter que le dossier ne contiendra que la partie du dépôt FGAddon spécifiée dans l'adresse URL. Cela signifie que Subversion vous permet de faire un «checkout» allant d'un seul fichier jusque à la totalité du dépôt distant.

Information et historique

Pour voir les informations sur le dépôt local, tapez: 

svn info

Et pour visualiser l'historique de la copie extraite du dépôt, tapez un de: 

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

Utilisation quotidienne

La commande principale de Subversion que vous allez utiliser est: 

svn add <chemin>

Cela enregistrera le fichier ou le répertoire <chemin> avec le dépôt local pour permettre de plus tard faire un «commit» pour l'envoyer au dépôt distant. Pour déplacer ou renommer un fichier ou répertoire, utilisez: 

svn mv <chemin1> <chemin2>

Cette commande doit être utilisée au lieu de le déplacer ou le renommer de la manière normale de votre système d'exploitation, afin que le changement soit enregistré dans le dépôt local. Pour supprimer un fichier ou répertoire dans le dépôt local, tapez: 

svn rm <chemin>

Pour voir l'état actuel du dépôt local, tapez: 

svn st

Valider la transaction

Toutes les opérations ci-dessus on eu lieu seulement sur le dépôt local - le dépôt FGAddon distant à SourceForge ne saura rien de ces modifications. Pour envoyer toutes les modifications à FGAddon, il faut faire un commit et valider les modifications avec: 

svn ci

Cette commande ouvrira un éditeur pour vous permettre d'écrire un message de commit informatif. Il est préférable d'assembler des petites commits modulaires afin que chaque commit correspond à un seul but. Vielliez noter que vous pouvez faire un commit à FGAddon seulement si vous avez un accès commit.

Branches

La notion de branches dans Subversion est en ce moment utilisée uniquement par le projet FlightGear pour étiqueter les versions stables. Mais si vous êtes curieux de ce concept de branches, lisez le chapitre gestion des branches dans le manuel de Subversion et le script de svnmerge.py qui peut simplifier le processus considérablement.

Git-svn

L'outil git-svn est utile pour ceux qui connaissent déjà comment utiliser les outils et les dépôts de git, ou ceux qui souhaitent avoir leur propre zone de développement d'aéronef privé. Git-svn établi un lien entre le dépôt Subversion distant de FGAddon et un dépôt git local. Pour ceux qui connaissent pas git, le lien de git-svn ainsi que le dépôt local est beaucoup plus compliqué à utiliser que les outils de Subversion indigènes. Pour plus d'informations sur l'utilisation de git, voyez Howto:Start using git. Les commandes suivantes présumeraient qu'un seul aéronef sera stocké dans le dépôt git local.

Mettre en place

Pour commencer, le système de gestion de versions git décentralisée doit être installé.

Clonage d'un seul aéronef

La première étape est de cloner l'un des aéronefs du répertoire trunk/ dans le dépôt Subversion distant: 

git svn clone <url_aéronef>

Pour l'adresse URL pertinente, vous devriez choisir l'un des scénarios de développement et trouver l'URL dans la section correspondante. L'adresse URL dépend si vous avez un accès commit FGAddon. La commande clone créera un dépôt git local contenant exclusivement l'aéronef d'intérêt et initialisera le lien git-svn.

Information et historique

Pour voir les informations sur le dépôt local à n'importe quel moment, tapez: 

git svn info
git branch -vva
git remote -v

Pour visualiser l'historique du clone extraite du dépôt, tapez: 

git log

L'utilisation quotidienne

La commande principale de git que vous allez utiliser est: 

git add <chemin>

Cela enregistrera le fichier ou le répertoire <chemin> avec le dépôt local pour permettre de faire un «commit» plus tard dans le dépôt git local. Pour déplacer ou renommer un fichier ou répertoire, utilisez: 

git mv <chemin1> <chemin2>

Notez cependant que l'historique de git est moins robuste que l'historique de svn. Consultez la section de déficience de git-svn en déplacement ou renommage de fichiers pour savoir comment mieux effectuer cette opération. Pour supprimer un fichier du dépôt local, tapez: 

git rm <chemin>

Pour voir l'état actuel du dépôt local, tapez: 

git status

Valider la transaction

Comme Git est un système de gestion de versions décentralisé, les modifications sont validées dans le dépôt local avec: 

git commit

Cette commande ouvrira un éditeur pour vous permettre d'écrire un message de commit informatif. Le commit est local et ne sera pas envoyé à FGAddon.

Branche dédiée FGAddon

Dans les exemples ci-dessus, une seule branche dans le dépôt local a été supposée. Si un interaction avec un dépôt git distant ou des branches dans le dépôt git local sont désiré, une stratégie différente est nécessaire. La raison étant que la branche qui se synchronise avec FGAddon doit maintenir un historique linéaire. Cela signifie qu'il faut seulement faire un «cherry-pick» pour chaque modification souhaité dans cette branche.

Dans cet exemple, deux branches seront créées dans le dépôt git local:

  • fgaddon: Cette branche sera dédiée à la synchronisation FGAddon et permettra de préserver un historique linéaire.
  • master: Une branche master pour le développement d'aéronef, permettant des «merges» et autres opérations d'historique non-linéaires.

En supposant un dépôt nouvellement cloné, créez la branche fgaddon avec: 

git branch fgaddon

Et allez à cette branche en tapant: 

git checkout fgaddon

La synchronisation avec FGAddon peut être effectuée sur cette branche. Pour tirer les développements de la branche master, utilisez la commande «cherry-pick» pour tirer une liste de commits en ordre séquentiel: 

git cherry-pick <hash_de_commit_1>
git cherry-pick <hash_de_commit_2>
git cherry-pick <hash_de_commit_3>
...

Pour voir la liste des commits prêt à être envoyée à FGAddon, avant de «dcommitting», tapez: 

git log git-svn..HEAD

Et pour visualiser les modifications dans un seul diff: 

git diff git-svn..HEAD

Synchronisation

Pour envoyer les modifications au dépôt FGAddon distant, allez d'abord à la branche dédiée fgaddon: 

git checkout fgaddon

Assurez-vous que le dépôt git-svn local est au courant avec toutes les modification qui sont arrivées dans FGAddon: 

git svn rebase

Enfin, poussez les changements à FGAddon avec: 

git svn dcommit

Déficiences de git-svn

Avertissement  De faire un git-svn clone du /trunk/ ou la totalité du dépôt n'est pas conseillé, car l'histoire entier du dépôt sera téléchargé, résultant en une énorme dépôt local, et en même temps à mettre une grande pression sur l'infrastructure open source de FlightGear.

Il faut savoir qu'il ya un certain nombre d'opérations dans lesquelles git-svn est déficients. Pour la plupart, les outils de svn devraient être utilisés à la place.

Copie de fichiers entre les aéronefs

Attention  Git-svn ne conserve pas l'histoire de la copie de fichiers normalement présents dans un dépôt Subversion.

Le plus important de ces opérations est de copier un part du contenu d'un aéronef de FGAddon à un autre. Dans ce cas, il faudra avoir accès commit à FGAddon et une copie du dépôt svn locale. En premier lieu, synchronisez les dépôts en poussant toutes modifications à FGAddon: 

git svn dcommit

Ensuite, dans le dépôt svn local, copiez le fichier en tapant: 

svn cp Aircraft/<aéronef1>/<chemin_de_fichier1> Aircraft/<aéronef2>/<chemin_de_fichier2>

Et validez la modification avec: 

svn ci

Revenez au dépôt git-svn local, et tirez les nouveaux fichiers: 

git svn rebase

En utilisant les outils subversion, cela évite que le backend du dépôt FGAddon n'accroît pas en taille, car les copies svn ne coûtent pas cher.

Déplacement ou renommage de fichiers

Attention  Git-svn ne conserve pas toujours l'histoire de déplacement ou renommage du fichier normalement présents dans un dépôt Subversion.

Ce problème provient du fait que l'historique de svn est plus robuste que celle de git. Les commandes svn mv et git mv ne sont pas équivalentes. La commande de Subversion enregistre l'historique de déplacement directement dans le dépôt alors que git ne le fait pas (à la place, git utilise des méthodes heuristiques pour tenter de détecter l'historique, après la validation). Le résultat de l'emploi de git-svn est que, souvent, le déplacement ne sera pas détecté et l'historique de FGAddon montrera un fichier ou un répertoire étant supprimé et un autre ajouté. Également, le backend du dépôt FGAddon augmentera en taille, alors que svn mv ne causera pas une augmentation importante. Si vous souhaitez d'avoir un bilan historique correct dans le dépôt FGAddon et d'être attentif à la santé du backend du dépôt, il est conseillé de sautez temporairement aux outils Subversion. Dans le premier coup, synchronisez les dépôts: 

git svn dcommit

Ensuite, dans le dépôt svn local, déplacez ou renommez le fichier ou répertoire: 

svn mv Aircraft/<aéronef>/<chemin_de_ficher1> Aircraft/<aéronef>/<chemin_de_ficher2>

Et faites le commit: 

svn ci

Retournez dans le dépôt git-svn local, et tirez les modifications avec: 

git svn rebase

Copie de fichiers dans un seul aéronef

Juste comme la commande svn mv enregistre les informations de déplacement directement dans le dépôt, la commande svn cp enregistre également les informations de la copie. Donc, si vous souhaitez copier un fichier de texte et de le modifier, en utilisant les outils natifs de Subversion au lieu de git-svn pour cette opération permet que l'historique du fichier soit conservée en permanence dans le dépôt FGAddon.

Propriétés dans Subversion

Attention  Pour l'instant, git-svn ne supporte que la propriété svn:executable. Tout autres propriétés sont ignorées et ne peuvent pas être ajoutées, modifiées ou supprimées dans le copie git-svn de l'aéronef.

En interne, Subversion identifie les fichiers binaires en utilisant la propriété svn:mime-type du dépôt. Mais, comme git-svn ne peut pas ajouter cette propriété en utilisant la commande git add, le résultat est que les fichiers binaires seront traités comme des fichiers de texte. Des diffs binaires seront visibles en utilisant svn diff ou git diff, et un diff binaire sera envoyé a la liste de diffusion FGAaddon commitlogs. Comme ceci n'est pas uniquement un problème de git-svn, veuillez consulter la section de diffs binaires pour éviter ce problème.

Protocoles autre que svn+ssh

La commande git svn init reproduit l'histoire entière d'un aéronef dans le dépôt local. Cette procédure génère un commit ID git ou hash pour chaque révision de Subversion. Le problème est que le commit ID git est dépendant du protocole utiliser pour accéder le dépôt Subversion (sans doute un bug de git). Alors: 

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

et 

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

créeraient deux dépôts git different et incompatible, pourtant qu'ils contiennent les mêmes données. Au début l'incompatibilité ne serait pas apparent, mais le problème reviendrait plus tard. En supposant que quelqu'un avec un accès FGAddon lecteurs seule utilise la méthode https, puis il demande a un gardien de FGAddon d'appliquer ces commits. Le gardien utiliserait svn+ssh, le seul protocole avec un accès écriture. Quand le gardien essait de faire un "merge" du dépôt https dans sa copie svn+ssh, git dirait que le deux dépôts n'ont aucune histoire en commun, et marquerait chaque commit en conflit.

Alors si vous voulez amélioré un aéronef, il faut toujours utiliser svn+ssh, même si vous n'avez pas un accès FGAddon en écriture. svn+ssh n'a pas besoin de l'accès en écriture, mais seulement un enregistrement à SourceForge.

Concepts de développement FGAddon

Nouveaux aéronefs

Pour ajouter un nouvel aéronef au dépôt FGAddon, les outils SVN sont nécessaires. Si vous rencontrez des problèmes avec la propriété svn:mime-type en ajoutant un nouvel aéronef, voyez la section des problèmes de mime-type pour voir comment résoudre ce problème. Également, si vous avez un problème de propriété svn:executable, consultez la section de bit exécutable.

svn import

Avertissement  La commande svn import décrit ci-dessous enverra le contenu entier du répertoire spécifié directement dans FGAddon sans avertissement et sans un moyen d'annuler l'opération. Par conséquent, une attention particulière doit être prise lors de la spécification du répertoire pour télécharger dans FGAddon, ainsi que le répertoire FGAddon de destination. Voyez la section svn add ci-dessous pour un moyen moins dangereux pour ajouter un nouvel aéronef.

La commande svn import est le moyen le plus simple d'ajouter un nouvel aéronef et ne nécessite aucune copie locale du dépôt. Pour commencer:

  1. Créez un répertoire vide pour l'aéronef.
  2. Copiez les fichiers de l'aéronef dans ce répertoire.
  3. Contrôlez soigneusement tout fichiers pour vous assurer qu'il n'y a pas de fichiers cachés ou temporaires qui ne devraient pas être téléchargés à FGAddon.

En supposant l'avion de «Dead Simple Human Powered Airplane» (DaSH PA ou DaSH), par exemple, situé dans le répertoire DaSH/, sur la ligne de commande, tapez: 

svn import DaSH/ svn+ssh://<identifiant>@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 ."

Où <identifiant> est votre nom d'utilisateur à SourceForge. Cette commande ajoutera tous les fichiers dans FGAddon en utilisant un message de commit en anglais avec la ligne de résumé Initial import of the DaSH human powered aircraft., suivie d'une ligne vide, puis une description détaillée indiquant l'origine ou les discussions sur l’aéronef. Pour voir si l'addition de l'aéronef a été un succès, tapez: 

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

Ou visitez l'interface de web FGAddon. L'aéronef peut être alors extrait comme décrit dans la section de scénarios de développement.

svn add

Si une copie locale du tronc de FGAddon est présente, la commande svn add peut être utilisée à la place. Ceci est beaucoup plus sûr que la commande svn import, car les modifications peut être revérifiées avant de faire le commit. Dans le répertoire Aircraft/ du dépôt local, créez le répertoire DaSH/. Cela peut être vide ou contenir tout fichiers de l’aéronef initial. Ensuite sur la ligne de commande, ajoutez l'aéronef au dépôt local avec: 

svn add DaSH/

Puis vérifiez soigneusement les modifications avant de faire le commit: 

svn st

Et envoyez les modifications à FGAddon avec: 

svn ci

Un éditeur, souvent vi[10], ouvrira et le message de commit peut être composé. De même, le message de commit peut être spécifié sur la ligne de commande avec: 

svn ci -m "<ligne_de_sujet>\n\n<description_détaillée>"

Blockage de commit par pre-commit hooks

Parfois quand vous faites des commits à FGAddon, le commit sera bloqué avec le message: 

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

C'est dû à la présence de deux scripts de dépôt appelés «pre-commit hooks» qui vérifient la qualité du commit, et le bloquera si c'est un ficher de texte avec un mime-type binaire ou s'il y a un bit exécutable. Ces scripts sont tous simplement là pour protéger le dépôt et préserver sa santé.

Problèmes de mime-type

Dans certains cas en utilisant les outils svn, lors d'un commit pour ajouter des fichiers à FGAddon, le commit sera bloqué avec le message: 

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'

Malgré les messages de l'ajout ou l'envoi de fichiers, le dépôt FGAddon n'aura pas changé. Ce message est créé par le script pre-commit de procédure automatique (en anglais, «repository pre-commit hook script») qui vérifie si le propriété svn:mime-type est présent sur un fichier de texte connu et si le mime-type est d'un format binaire, et dans ce cas le commit est bloqué. Ce blocage est destiné à protéger le dépôt. Les nouveaux clients SVN sont dépendents d'une bibliothèque logicielle 3ème partie appelée libmagic qui détecte les fichiers XML de l'aéronef comme ayant le mime-type binaire de application/xml. Le résultat est que les fichiers XML sont traités comme fichiers binaires dans le dépôt. Ce comportement est tout à fait inacceptable, car les modifications ne peuvent pas être suivies sur la liste de diffusion flightgear-fgaddon-commitlogs ou dans l'historique du dépôt, et la taille des commits devient des ordres de grandeur plus grande. Ainsi ce comportement défectueux est bloqué pour la protection du projet FlightGear. Pour éliminer ce problème, suivez les instructions dans le message et, en utilisant les outils de ligne de commande, tapez: 

svn propdel svn:mime-type <nom_de_fichier>

Répétez cette opération pour chaque fichier texte indiqué dans le message d'erreur. Puis effectuez à nouveau le commit, en utilisant le message de commit enregistré dans le fichier de svn-commit.tmp. Le nom précis du fichier de message sera rapporté dans le message d'erreur de commit, mais vérifiez d'abord son contenu avec: 

cat svn-commit.tmp

Et refaites le commit: 

svn ci -F svn-commit.tmp
Fichier config Subversion

Le réglage automatique de propriété svn:mime-type peut être contrôlé en modifiant le fichier config de Subversion. Tout d'abord dans la section [miscellany], assurez-vous que les auto-propriétés sont activées: 

enable-auto-props = yes

Ensuite dans la section [auto-props], ajoutez: 

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

Ce sont tous les types de fichiers de texte que le hook script vérifiera si le mime-type est d'un format de texte. Notez que des nouveaux types de fichiers de texte seront sans doute ajoutés à l'avenir. Ces ajouts peuvent être soit dans le fichier de configuration de l'utilisateur situé à ~/.subversion/config (ou %USERPROFILE%\AppData\Roaming\Subversion\config sous Windows) ou, si un fichier de configuration d'utilisateur n'est pas définie, le fichier de configuration global à /etc/subversion/config (ou %APPDATA%\Subversion\config sous Windows).

Bit exécutable

Un autre message de blocage lors d'un commit pour ajouter des fichiers à FGAddon en utilisant les outils SVN est: 

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'

Ce message sera probablement vu uniquement sur les systèmes Mac OS X et GNU/Linux. Ce message est émis par un script de procédure automatique pre-commit (en anglais, «repository pre-commit hook script») qui vérifie si la propriété Subversion svn:executable est réglée et, si oui, le commit est bloqué. Ceci est une mesure de sécurité, car aucun fichier de l'aéronef devrait être exécutable. Pour supprimer ce problème, suivez les instructions dans le message et, en utilisant les outils de ligne de commande, tapez: 

svn propdel svn:executable -R

Puis effectuez à nouveau le commit, en utilisant le message de commit enregistré dans le fichier de svn-commit.tmp. Le nom de fichier sera signalé dans le message d'erreur de commit, mais d'abord vérifiez son contenu avec: 

cat svn-commit.tmp

Et effectuez le commit à nouveau: 

svn ci -F svn-commit.tmp

Diffs binaires

Avertissement  Une mauvaise valeur ou l'absence de la propriété de mime-type sur un fichier binaire provoquera un diff binaire.

En regardant le résultat de svn diff (ou git diff, si vous utilisez git-svn) et en lisant les messages de la liste de diffusion FGAddon commitlogs, parfois vous verrez un grand nombre de caractères non identifiables. Ceci est un diff binaire, le résultat de montrer les différences entre les fichiers binaires comme si ils était des fichiers de texte. Bien que ce ne soit pas un problème pour le fonctionnement du dépôt, la situation n'est pas idéal et fait que ce soit plus difficiles d'effectuer un examen des changements.

Pour résoudre le problème, d'abord les fichiers binaires avec la propriété de svn:mime-type problématique doivent être identifiés. La commande Subversion suivante peut être utilisée: 

svn propget svn:mime-type <nom_de_fichier>

Parce que cette tâche de vérifier chaque fichier peut être fastidieux, le script Python suivant simplifie et automatise la procédure pour identifier tout fichiers binaires avec un problème de mime-type:

Script Python 2/3: Trouver tout fichiers binaires sans un propriété de svn:mime-type, ou avec une mauvaise valeur.

Régler le problème

Comme git-svn ne peut pas régler ou modifier la propriété svn:mime-type, une copie svn checkout de l'aéronef est nécessaire. La propriété mime-type peut ensuite être réglée sur la valeur par défaut binaire de Subversion avec: 

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

Vous pouvez également utiliser les commandes shell suivantes pour automatiser le processus:

Commandes shell: Régler les valeurs spécifiques svn:mime-type sur une liste de fichiers binaires connues.

Services de développeur à SourceForge

Le projet FlightGear est hébergé sur l'infrastructure open source SourceForge. Cette section sur les services de développeurs fera la démonstration de certains outils utiles que vous pouvez exploiter. SourceForge est composé de deux catégories de services:

L'infrastructure de projet
Le projet FlightGear utilise les services de projet à SourceForge. Ces services sont pour des projets de logiciels autonomes.
L'infrastructure de développeur
Ce sont des services disponibles à toute personne possédant un compte SourceForge, et sont disponibles sur votre page d'accueil SourceForge. Cela inclut d'être capable de créer des dépôt de gestion de versions multiples (svn, git, hg), des wikis, des forums, des équipes de développement, des blogs et des traqueurs de billets (pour les bogues, demandes de soutien, tâches, etc.), avec tout étant accessible au public.

Au lieu de créer un nouveau projet, tous les développements pour le projet FlightGear devraient être basée sur l'infrastructure de développeur.

Dépôt git de développeur

Pour créer votre propre dépôt git distant, ici pour le développement de l'avion FGAddon fkdr1:

  • Sur votre page de profil à https://sourceforge.net/u/<identifiant>/profile/, choisissez Personal tools -> Add Tools
  • Click to install -> git.
  • Changez l'étiquette à fkdr1 FGAddon git-svn repository.
  • Changez le code path à code-fkdr1. Le préfixe code-* permet de différencier entre ce dépôt et les forum-*, wiki-*, et autres répertoires.

Le dépôt se trouvera à https://sourceforge.net/u/<identifiant>/code-fkdr1/ci/master/tree/.

Équipes de développement

Si vous et un groupe d'amis souhaitez développer l'un des aéronefs FGAddon en privé et en équipe, en supposant que vous avez déjà contacté les auteurs de l'aéronef originaux et que l’aéronef n'est pas en développement actif, vous devriez créer une équipe de développement à SourceForge. Un chef d'équipe devrait être nommé pour configurer l'équipe dans leur compte SourceForge. En supposant que vous souhaitez développer l'aéronef «ornithopter», les étapes sont:

  • Choisissez Personal tools -> Admin.
  • Cliquez sur User Permissions.
  • Cliquez au fond sur Add a new group.
  • Changez le nom à ornithopter, et enregistrez.
  • Cliquez sur Add dans le groupe ornithopter et ajoutez les noms de SourceForge de tous les membres de votre équipe.

Après la création d'un dépôt git privé dans le compte du chef, l'équipe de développement devrait être mis en place pour le dépôt.

  • Allez au dépôt dans votre compte SourceForge.
  • Cliquez sur Admin - <nom_de_dépôt> et sélectionnez Permissions.
  • Dans la section Write, enlevez Developer et ajoutez ornithopter.
  • Cliquez sur Save.

Chaque membre de l'équipe de développement aura maintenant un accès commit au dépôt privé.

Communications de l'équipe

Pour aider au développement en équipe, l'infrastructure SourceForge permet de créer plusieurs forums de discussion dédiés. Cela peut être soit pour un projet SourceForge ou sur la page du développeur à SourceForge. Cela permet au chef de l'équipe de créer un forum dédié exclusivement au développement de l'aéronef d'intérêt. En continuant avec l'exemple de l'ornithoptère, les étapes pour le chef d'équipe sont simples:

  • Sur votre page de profil à https://sourceforge.net/u/<identifiant>/profile/, choisissez Personal tools -> Admin.
  • Cliquez sur l'option Tools dans le menu situé à gauche.
  • Cliquez sur Discussion dans la section Click to install.
  • Changez l’étiquette à Ornithopter forum, et le chemin à forum-ornithopter, par exemple. Le préfixe forum-* permet de différencier entre ce répertoire et les code-*, wiki-*, et autres répertoires.
  • Cliquez sur Save.

D'autres détails sont fournis dans la documentation de discussion à SourceForge.

Scénarios de développement

Développeur individuel

Note  Scénario de développement: Vous êtes un développeur individuel et utiliserez les outils de Subversion indigènes.

Ce scénario de développement est de loin le plus simple et devrait être utilisé dans la plupart des cas. Si vous utilisez le client de Subversion en ligne de commande, vous pouvez faire une extraction d'un aéronef individu avec: 

svn co svn+ssh://&lt;identifiant&gt;@svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/wrightFlyer1903

Où <identifiant> est votre nom d'utilisateur à SourceForge. Alternativement vous pouvez faire une extraction de tous les aéronefs avec: 

svn co svn+ssh://&lt;identifiant&gt;@svn.code.sf.net/p/flightgear/fgaddon/trunk flightgear-fgaddon

Si vous n'avez pas un accès commit, tapez un de: 

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

Pour utiliser le nouveau dépôt svn local, consultez les instructions de subversion.

Développeur individuel (git-svn)

Note  Scénario de développement: Vous êtes un développeur individuel et utiliserez les outils de git-svn.

Cette méthode est plus compliquée que l'utilisation des outils indigènes de SVN, mais est utile lorsque l'accès commit FGAddon est absent, car plusieurs commits locaux peuvent être faites pour être plus tard envoyés aux auteurs d'aéronef originaux, à la liste de diffusion de développement ou au forum. Pour créer un clone de l'aéronef de choix dans un nouveau dépôt git local, tapez: 

git svn clone svn+ssh://<identifiant>@svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/<aéronef>

Où <identifiant> est votre nom d'utilisateur à SourceForge et <aéronef> est le répertoire dans le dépôt FGAddon. Cela est valides si vous avez un accès commit ou non.

Pour utiliser le nouveau dépôt git locale, consultez les instructions de git-svn et faites attention à ses déficiences.

Télécharger sur Sourceforge

Afin de partager votre développements locaux, les modifications peuvent être téléchargées dans un dépôt git distant sur l'infrastructure SourceForge. Pour cela, un dépôt git de développeur doit d'abord être créé sous votre profil à SourceForge. Ajoutez ensuite ce dépôt distant comme un «remote»: 

git remote add origin ssh://<identifiant>@git.code.sf.net/u/<identifiant>/code-<aéronef>/

Et envoyez la branche master où les développements sont situés avec: 

git push --set-upstream origin master

Les modifications dans le nouveau dépôt sera visibles à travers de l'interface web à https://sourceforge.net/u/<identifiant>/code-<aéronef>/ci/master/tree/.

Envoi de changements d'un dépôt git externe à FGAddon

Note  Scénario de développement: Vous êtes un développeur individuel avec l'accès commit à FGAddon autorisé et vous souhaitez transféré les commits d'un dépôt git distant dans FGAddon en utilisant un dépôt git-svn local provisoire.

En premier lieu, clonez l'aéronef de FGAddon dans un dépôt git-svn local avec: 

git svn clone svn+ssh://<identifiant>@svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/<aéronef>

Cette commande créera un nouveau dépôt git local lié à FGAddon en utilisant git-svn. Si l'aéronef est nouveau et n'est pas présent dans le dépôt FGAddon, consultez les instructions pour ajouter un nouvel aéronef dans FGAddon. Ensuite, configurez le dépôt git distant comme un «remote», et faites un «fetch» avec: 

git remote add <nom> <url>
git fetch

Où <url> est l'adresse URL du dépôt git distant. Finalement, faites une liste ordonnée de tous les hashs de commit à être envoyée dans FGAddon, du premier au dernier, et faites des «cherry-picks» sur la branche master git-svn: 

git cherry-pick <hash_de_commit_1>
git cherry-pick <hash_de_commit_2>
git cherry-pick <hash_de_commit_3>
...

Viellez noter que le dépôt local git-svn ne devrait avoir qu'une seule branche master et soit composé uniquement de «cherry-picking». Pour visualiser les modifications en file d'attente pour l'envoi vers FGAddon, tapez: 

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

Ensuite, pour envoyer les modifications à FGAddon, tout d'abord tirez toutes les modifications distantes, et puis envoyez les commits avec: 

git svn rebase
git svn dcommit

Le dépôt local provisoire peut être ensuite supprimé.

Connexion d'un dépôt git existant à FGAddon

Note  Scénario de développement: Vous êtes un développeur individuel ou un chef d'une équipe avec l'accès commit à FGAddon et vous souhaitez relier un dépôt git distant préexistant avec FGAddon pour envoyer toutes modifications à FGAddon.

Si un dépôt git distant existe déjà et contient un aéronef développé, il est possible de le relier au dépôt FGAddon distant en utilisant les outils de git-svn. Les instructions suivantes utilisent la technique de la branche dédiée FGAddon. En premier lieu, créez le lien à FGAddon en utilisant git-svn dans le dépôt de l'aéronef: 

git svn init svn+ssh://<identifiant>@svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/<aéronef>

Où <aéronef> est le répertoire d'aéronef dans FGAddon. Viellez noter que cette étape peut être effectuée sans un accès commit pour FGAddon, en utilisant à la place un URL SVN en lecture seule, mais les modifications ne peuvent pas être repoussées à FGAddon. Néanmoins, cela permet que les modifications dans FGAddon distant soient intégrées dans le dépôt git distant, ce qui simplifie la préparation des modifications pour soumission pour inclusion dans FGAddon en utilisant des patchs envoyés à la liste de diffusion ou envoyés par d'autres façons.

Maintenant, allez chercher l'état actuel du dépôt FGAddon distant: 

git svn fetch

L'historique SVN est téléchargé dans la branche remotes/git-svn. Pour envoyer les modifications à FGAddon, vous avez besoin d'une branche locale qui permet de suivre cette branche distante. Créez une branche fgaddon locale que vous allez utiliser pour envoyer les commits à FGAddon: 

git branch fgaddon remotes/git-svn

Après avoir effectué les commits des nouvelles modifications dans la branche master, pour pousser à FGAddon, faites un checkout de la branche fgaddon et l'actualiser au cas où quelqu'un a touché l'aéronef dans le dépôt FGAddon distant: 

git checkout fgaddon
git svn rebase

Cherry-pick les nouveaux commits de master à fgaddon pour préserver un historique linéaire: 

git cherry-pick <hash_de_commit_1>
git cherry-pick <hash_de_commit_2>
git cherry-pick <hash_de_commit_3>
...

Pour visualiser les modifications en file d'attente pour l'envoi vers FGAddon, soit comme commits ou comme un diff, tapez: 

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

Si tout semble correct, dcommit les commits locaux sur la branche fgaddon pour les envoyer vers le dépôt SVN FGAddon distant avec: 

git svn dcommit

Revenez à la branche master de développement locale: 

git checkout master

Pour obtenir les modifications de «upstream», vous pouvez soit les télécharger avec 

git svn fetch

ou les télécharger et effectuez un «rebase» de votre branche fgaddon: 

git checkout fgaddon
git svn rebase

Équipe de développement

Note  Scénario de développement: Tous les membres de l'équipe sont des gardiens du dépôt FGAddon, et toutes les commits sont faites directement à FGAddon, en utilisant soit svn ou git-svn.

La manière la plus simple de travailler ensemble dans une équipe est pour chaque développeur d'avoir soit une copie svn de FGAddon ou une copie git-svn de FGAddon, et tout le monde fait des commits directement dans FGAddon. La communication et coordination entre les membres de l'équipe peuvent être effectuées en utilisant un forum à SourceForge organisé par le chef de l'équipe ou en utilisant le forum de FlightGear. Dans ce scénario, l'équipe doit prendre l'initiative et chaque développeur applique pour un accès commit FGAddon.

Équipe de développement privée (git-svn)

Note  Scénario de développement: Un chef d'équipe agit comme gardien sur un dépôt git privé hébergé sur l'infrastructure interne de SourceForge, en utilisant git-svn pour pousser une branche dédiée fgaddon à FGAddon, et les membres de l'équipe font des commits directement au dépôt git privé ou font des «merge requests» de leur fork du dépôt privé.

Pour conserver tout en interne, l'ensemble de l'opération sera basé sur l'infrastructure officiel et sur des dépôts distants dans le profil de SourceForge (SF) de chaque utilisateur. Remarque pour le chef de l'équipe: vous devriez garder votre historique git-svn linéaire (ce qui signifie qu'une branche FGAddon dédiée doit être créée et les modifications manuellement «cherry-picked» dans cette branche). Dans la suite, l'appareil ornithoptère sera utilisé comme exemple.

L'équipe

Tout d'abord, chaque membre de l'équipe devrait enregistrer pour des comptes à SourceForge.

Chef de l'équipe

Configuration du dépôt privé

Ces étapes sont pour le chef de l'équipe. Dans votre profil d'utilisateur sur SourceForge, mettre en place un dépôt git avec l'étiquette Ornithopter FGAddon git-svn repository et le chemin de code code-ornithopter. Ensuite, créez un dépôt vide git local: 

$ mkdir ornithopter
$ cd ornithopter
$ git init

Liez le dépôt vide au répertoire de l'aéronef ornithopter dans le dépôt FGAddon distant et actualisez le avec: 

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

Replacez <identifiant> avec votre nom d'utilisateur SF. Mettre en place une branche spéciale de git-svn pour lier avec FGAddon et pour faire des dcommit pour envoyer les modifications à FGAddon: 

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

Et tirez le ornithopter de FGAddon: 

$ git svn rebase

Pour visualiser la configuration du dépôt git-svn local, tapez: 

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

Puis retournez à la branche master: 

$ git checkout master

Finalement, configurez le dépôt git distant comme un «remote»: 

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

Et envoyez la branche master au dépôt git distant: 

$ git push -u origin master

Pour visualiser la nouvelle configuration, tapez: 

$ git branch -vva
$ git remote -v

Le dépôt sera situé à https://sourceforge.net/u/<identifiant>/code-ornithopter/ci/master/tree/. Viellez noter que les informations de git-svn enregistrées dans le répertoire .git/svn ne seront pas poussées au dépôt distant à SoureForge, et donc le lien vers FGAddon sera seulement présent dans la copie locale du chef de l'équipe. Si nécessaire, le lien de git-svn peut être rétablie plus tard.

Configuration de l'équipe

Configurez une équipe de développement dédiée et l'accordez un accès commit au dépôt git-svn distant.

Pousser à FGAddon

Le dépôt git local du chef de l'équipe est utilisé pour faire des commits à FGAddon. L'historique doit être gardé linéaire dans la branche de fgaddon, alors «cherry-picking» est la seule façon d'avancer. Les instructions suivantes viennent de la section de développeur individuel (git-svn). Dans le dépôt git local, changez à la branche fgaddon avec: 

git checkout fgaddon

Tirez toutes les modifications qui ont eu lieu dans FGAddon: 

git svn rebase

Pour voire les commits dans la branche master qui ne sont pas dans la branche fgaddon, tapez un de: 

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

Sélectionnez manuellement les commits pour être envoyés à FGAddon et utilisez le «cherry-pick» pour tirer une liste de commits en ordre séquentiel: 

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

Ou pour faire un «cherry-pick» d'un ensemble de commits: 

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

Puis vérifiez ce qui est à envoyé: 

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

Envoyez les modifications à FGAddon, envoyez les modifications dans la branche git de fgaddon au dépôt git distant, et retourez à la branche master: 

git svn dcommit
git push
git checkout master

Finalement faites un merge des commits de git svn avec leurs nouveaux hashes de la branche fgaddon, et envoyez tout au dépôt git distant: 

git merge fgaddon
git push

Membres de l'équipe

Travailler avec le dépôt

Chaque membre de l'équipe devrait faire un clone du dépôt git privé: 

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

Replacez <identifiant> avec votre nom d'utilisateur SourceForge, et <identifiant_chef> avec celle du chef de l'équipe.

Forking et merge requests

Alternativement, chaque membre de l'équipe peut faire un fork du dépôt git distant sous leur compte de SourceForge:

  • Allez à https://sourceforge.net/u/<identifiant_chef>/code-ornithopter/ci/master/tree/, où <identifiant_chef> est le nom d'utilisateur de SourceForge du chef de l'équipe.
  • Cliquez sur Fork.
  • Configurez le chemin à code-ornithopter et changez l'étiquette comme vous voulez.

Développez et poussez à votre fork, puis faites une demande de fusion en cliquant sur le bouton Request Merge.

Références

  1. ↑ David Murr (Apr 9, 1996). FlightGear proposition 1.0: "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@". Publié sur le newsgroup rec.aviation.simulators.
  2. ↑ David Murr (1996). FlightGear proposition 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 proposition 3.0: FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here". Publié sur le la liste de diffusion flight-gear@infoplane.com.
  4. ↑ David Murr (Sep 11, 1998). FlightGear proposition 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!@. Publié sur le forum de FlightGear.
  6. ↑ James Turner (May 20, 2010). [Flightgear-devel] Re: Flightgear git repositories (was Re: GIT or CVS - Confusion) Publié sur la liste de diffusion flightgear-devel.
  7. ↑ Cedric Sodhi (Oct 18, 2011) [Flightgear-devel] FGData Split Completed - a.k.a Life after the Split Publié sur la liste de diffusion flightgear-devel.
  8. ↑ FlightGear Policy Document and Roadmap, document provisoire.
  9. ↑ La liste GNU de compatibilité de licence.
  10. ↑ Documentation de Vim.
Retrieved from "https://wiki.flightgear.org/w/index.php?title=Fr/FGAddon&oldid=139359"