Ca/FGAddon

S'està traduint aquest article.

L'hangar oficial d'aeronaus FGAddon és un repositori de control de versions, allotjat a l'infraestructura SourceForge de FlightGear, i usat per al desenvolupament diari de les aeronaus del simulador. FGAddon és un repositori de control de versions de Subversion. Aquestes aeronaus no formen part del paquet base (les aeronaus que s'inclouen al paquet base) — el Cessna 172P i l'UFO — es mantenen al repositori de FGData), però apareixen amb cada versió estable a les pàgines de descàrrega de FlightGear.

El repositori de desenvolupament d'aeronaus FGAddon s’ha de considerar inestable. Quan utilitzeu una versió estable de FlightGear, el millor és obtenir avions amb un número de versió coincident del programa base actual que apareix a les pàgines de descàrrega de FlightGear. Tanmateix, com les versions estables de FlightGear 3.4 en endavant estan etiquetats i presents al repositori de FGAddon, les eines de Subversion poden ser una manera convenient d’obtenir aeronaus individuals o tot l’hangar oficial d’aproximadament 500 avions. També, si utilitzeu les últimes versions o una versió autocompilada de FlightGear dels repositoris de control de versions de Git de FlightGear, utilitzant el FGAddon permet actualitzar l’avió a les últimes versions de desenvolupament.

Història

Icona original de Win95

El projecte FlightGear va ser concebut el 8 d'abril de 1996 per David Murr, que va proposar un nou simulador de vol per ser desenvolupat per voluntaris^[1]^[2]^[3]^[4]. Part dels objectius inicials van ser desenvolupar rutines gràfiques 2D i 3D per al simulador. No obstant això, aquesta va ser una tasca enorme que va acabar sense finalitzar a principis de 1997, ja que el desenvolupador principal, Eric Korpela, estava acabant la seva tesi. Per tant, a partir del 16 de maig de 1997, Curtis Olson va rellançar el desenvolupament amb un nou projecte basat en les biblioteques d'OpenGL, que permetria crear un simulador de vol funcional en un curt període de temps.^[5] Les primeres contribucions van ser de repositoris de control de versions CVS de flightgear i simgear originals.

A mesura que el projecte va créixer, també ho va fer la mida, la quantitat i la qualitat dels actius de FlightGear. Aquests actius no estaven organitzats i estaven dispersos per diferents parts d'Internet. Per tant, es va decidir que gran part d’aquest contingut de FlightGear es reuniria i s’emmagatzemaria de manera conjunta en un nou repositori CVS centralitzat anomenat fgdata, que es va crear el 22 d’octubre de 2000. Per permetre la redistribució legal d’aquests actius com a part de la distribució de FlightGear, s’adoptava una política de GPLv2.

Al maig del 2010, el desenvolupament va ser interromput malauradament per "l'incident del cafè" que va resultar en la pèrdua del servidor domèstic de Curtis que allotjava tots els repositoris de FlightGear^[6]. Aquests esdeveniments van resultar en un migració massiva de tots els repositoris CVS als repositoris de Git. A causa de problemes d’amplada de banda, es va decidir que els nous repositoris s’alternessin a la infraestructura de codi obert Gitorious.

Amb el temps que el projecte va créixer, la mida i l'abast del repositori de fgdata es va multiplicar, principalment a causa del creixent nombre d’avions emmagatzemats a $FG_ROOT/Aircraft, de manera que una divisió era inevitable. Gijs de Rooy va organitzar un primer intent de separació i es va anunciar el 18 d’octubre de 2011^[7]. Cada avió es va col·locar en el seu propi repositori de Git i tots els avions vinculats de nou a fgdata mitjançant un enfocament del submodul Git. No obstant això, aquest intent va fallar i va ser abandonat. A partir d'aquesta data fins a finals de 2014, el disseny de la divisió fgdata es va discutir a la llista de correu de desenvolupament i es va resumir a l'article wiki de FlightGear Git: dividint fgdata. En les etapes de planificació, els repositoris es coneixien com a fgdata-old dividint-se en FGData (també conegut com a fgdata-new) i FGAddon (també conegut com a flightgear-aircraft i fgaircraft). Després de mitja dècada de planificació, es va decidir que la millor solució per al desenvolupament d’avions de FlightGear seria un únic repositori de Subversion centralitzat. Això facilitaria la gestió i el manteniment comunitari de l’avió, alhora que proporciona modularitat i descàrregues més petites i mides de repositoris locals més petits.

A finals de 2014, Gitorious, el proveïdor de la infraestructura de codi obert per al codi font de FlightGear i els repositoris de dades, va anunciar que tancaria els seus serveis fins al maig de 2015 a causa de la seva adquisició per GitLab. Això va motivar la divisió de fgdata-old i un canvi a l'infraestructura de codi obert SourceForge per allotjar els repositoris VC. Altres parts de la infraestructura de FlightGear ja estaven allotjades per SourceForge, fent que el moviment fos natural. Segellant l’acord, SourceForge va acceptar per escrit allotjar l’enorme col·lecció d’avions de FlightGear, la mida de la qual no té rival en cercles de codi obert. Avui en dia, el repositori SVN de FGAddon, juntament amb la major part de la infraestructura del projecte FlightGear, està allotjat a SourceForge.

A l'agost de 2015, es va escriure un nou document de política de FlightGear per codificar els estàndards no escrits del projecte^[8]. Amb aquest document, la política de llicències dels avions de FlightGear allotjada a FGAddon ha estat actualitzada ed GPLv2-only a GPLv2+. Per combatre la proliferació de llicències, cal evitar complicacions mitjançant el treball d’una aeronau a una altra, i per la integritat i el bon projecte del FlightGear, es recomana que tot el contingut original (allotjat a FGAddon o en qualsevol altre lloc) sigui llicenciat amb GPLv2+.

Obtenint aeronaus

Consell Si esteu interessats a obtenir aeronaus per a llançaments de FlightGear estables i no teniu coneixement del control de versions, heu de visitar el Hangars de FlightGear per descarregar-les.

Precaució Si les versions de les aeronaus de FlightGear i FGAddon no coincideixen, poden aparèixer errors i el suport en versions no compatibles no serà efectuat per la comunitat de FlightGear.

Amb accés a les eines Subversion (SVN), el repositori de control de versions de FGAddon pot ser una forma convenient d’obtenir avions per utilitzar-los dins d’una versió FlightGear específica directament des de la font oficial. When using the nightly builds or a version controlled copy of FlightGear, the most up to date in-development versions of the aircraft should be used so the versions match. The following describes how to use the official repository to obtain aircraft from the perspective of a FlightGear user.

Preparació

To use the FGAddon repository, the Subversion tools need to be installed:

MS Windows: Install one of the many Subversion clients. For example SlikSVN is one of the best command line versions and the best for aircraft development, and TortoiseSVN provides a user friendly graphical user interface (GUI) by integrating into Windows Explorer.
Mac OS X: Install the official Subversion client.
GNU/Linux: Install the Subversion client via the package manager. This will usually be in a package called subversion-*.{rpm,deb}.

Directori de FGAddon

To know how to use the FGAddon repository, an understanding of the repository directory layout is essential.

/trunk: This base directory is where the in-development versions of the aircraft are located.
/branches/release-x.y.z/: These directories correspond to the specific stable FlightGear releases.

The web interface for the FGAddon repository allows all of the aircraft to be browsed.

Descàrrega

Aircraft to be downloaded

Firstly, choose an aircraft to download. The Bell Boeing V-22 Osprey will be used in this example.

Command line

To download the aircraft for FlightGear 3.4, simply type:

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

To obtain the in-development version, type:

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

If all of the ~500 aircraft from the repository are desired - beware that this will be a huge download of over 6 GB - use the following command:

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

When using a stable FlightGear release, for example FlightGear 2016.1, to obtain all of the FGAddon aircraft to match the installed FlightGear version, use:

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

GUI clients and TortoiseSVN

When using one of the Subversion GUIs (graphical user interfaces), simply copy one of the above https:// URLs and use that in the GUI (each GUI is different, so see the relevant documentation for help). For the unique TortoiseSVN tool, simply:

In Windows Explorer, create a new empty folder for the aircraft (or aircraft collection).
In the new folder, right click and select SVN Checkout....
Copy and paste the URL, for example https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/V22-Osprey, leave all other settings as they are, and import by clicking on OK.

For more details, see the TortoiseSVN documentation. Note that there is an option to install the command line tools when installing TortoiseSVN.

Flying

To use the newly downloaded aircraft, please see the Howto:Install aircraft article, skipping the instructions for downloading and unzipping the aircraft.

Updates

With a checked out copy of the /trunk in-development version, the aircraft can be updated to the latest version using the command:

svn up

Aircraft development

Consell The FlightGear community encourages aircraft development directly within FGAddon.

Contact the original aircraft authors

The first step for developing and advancing the aircraft of the official FlightGear hangar, or from one of the private hangars for that matter, is to make contact with the original aircraft author(s). Their names can be found within the *-set.xml file, within the <authors> XML tag. Often the contact email address will be listed in a README file or some other text file in the base aircraft directory. If not, contact can sometimes be established via the FlightGear development mailing list. Contacting the original authors is important to see if the aircraft is currently being actively developed, and if you can join in as part of the development team.

SourceForge account

To work on the official aircraft collection, a SourceForge account should first be set up. This will allow to either directly commit to the FGAddon repository, if commit access has been been granted, or to work in as part of a SourceForge development team. The registration process is lightning quick and the SourceForge developer infrastructure and developer services will be accessible in under a minute.

Commit access

Before obtaining commit access, an all-out effort to contact the original author(s) should be made to determine if the aircraft is actively being developed. If this is unsuccessful, sign up for the FlightGear development mailing list and ask for help there. If the aircraft has a current maintainer, you will be directed as to how to proceed with development. Otherwise ask if someone could volunteer to mentor you in the process of becoming an aircraft developer with full commit access.

To obtain commit access, you will first need:

To demonstrate your capabilities and development skills.
To show that you understand the FlightGear policy document.
To show an understanding of the GPL licensing issues, and that you can be trusted not to use copyrighted, non-GPL material.
To earn the trust of the FlightGear community.

These easy to jump over hurdles are simply designed to protect against repository corruption or pollution of the repository with illegal content.

To have your changes committed into the FGAddon repository, you should discuss and coordinate with the original aircraft author, or your mentor, for the best way to proceed. Depending on the development scenario, this maybe by merge request, file transfer, the primitive patch system, or any other convenient way. Once you believe you have proven your capabilities and you are knowledgeable about GPL licensing issues, you should write a mail to the development mailing list asking if you can be granted commit access, providing your SourceForge username.

FGAddon commitlog mailing list

To follow all changes which occur in the FGAddon repository, subscribe to the dedicated Flightgear FGAddon commitlogs mailing list. One email is sent per commit, as the commit is made.

Version control tools

To access FGAddon and use it for aircraft development, the Subversion or SVN version control tools are needed. Alternatively git-svn provides an interface for those who prefer the git version control tools.

Subversion

Set up

The FGAddon aircraft hangar is stored in a remote Subversion repository located on the SourceForge infrastructure, and therefore it is simplest to use the SVN tools for aircraft development and will cause the least problems. See the Subversion installation section for setting up the tool chain.

Repository checkout

The first step is to 'checkout' a copy of either the repository trunk or one of the aircraft in the trunk:

svn co <url> <dir>

For the relevant URL to use, you must chose one of the development scenarios and find the URL in that section. This command will create a local subversion repository copy in the given <dir> directory. Note that this will only contain the part of the FGAddon repository specified in the URL. This means that Subversion allows you to checkout either a single file all the way to the entire remote repository.

Information and history

At any point to see information about the local repository, type:

svn info

To see the history of the checked out copy of the repository, type one of:

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

Daily usage

The main Subversion command you will be using is:

svn add <path>

This will register the file or directory <path> within the local repository to allow it to later be 'committed' and sent to the remote repository. To move or rename a file or directory, use:

svn mv <path1> <path2>

This should be used rather than normal file moving/renaming so that the change is tracked in the local repository. To remove a file from the local repository, type:

svn rm <path>

To see the current status of the local repository, type:

svn st

To update the local repository with changes in the remote repository, type:

svn up

Committing changes

All of the above operations only occur on the local repository copy - the remote FGAddon repository at SourceForge will know nothing of these changes. To send all your changes to FGAddon, you need to commit the changes:

svn ci

This will open up an editor to allow you to write an informative commit log message. When committing, it is best to make small modular commits so that each commit corresponds to a single purpose. Note that you can only commit to FGAddon if you have commit access.

Branching

The concept of Subversion branching is currently only used in the FlightGear project for tagging the stable releases. However if you are curious about branching, see the Branching and Merging chapter of the Subversion manual, and the svnmerge.py script which can greatly simplify the process.

Git-svn

The git-svn tool is useful for those who are already familiar with using git repositories, or those who wish to have their own private aircraft development playground. Git-svn provides a bridge between the remote FGAddon Subversion repository and a local git repository. For those unfamiliar with git, the git-svn bridge together with the git repository is far more complicated to use than the native Subversion tools. For more information on using git, see Howto:Start using git. The following will assume that only a single aircraft will be stored in the local git repository.

Set up

The git distributed version control system needs to first be installed.

Cloning a single aircraft

The first step is to 'clone' a copy of one of the aircraft in the remote Subversion trunk:

git svn clone <aircraft_url>

For the relevant aircraft URL to use, you must chose one of the development scenarios and find the URL in that section. The URL depends on your FGAddon commit access status. The clone command will create a local git repository containing solely the aircraft of interest, and initialise the git-svn bridge.

Information and history

At any point to see information about the local repository, type:

git svn info
git branch -vva
git remote -v

To see the history of the checked out copy of the repository, type:

git log

Daily usage

The main git command you will be using is:

git add <path>

This will register the file or directory <path> within the local repository to allow it to later be 'committed' to the local git repository. To move or rename a file or directory, use:

git mv <path1> <path2>

However note that git history is not as robust as svn history. See the git-svn file moving/renaming deficiency section for how to better perform this operation. To remove a file from the local repository, type:

git rm <path>

To see the current status of the local repository, type:

git status

Committing changes

As git is a distributed version control system, changes are committed to the local git repository.

git commit

This will open up an editor to allow you to write an informative commit log message. The commit is local and will not be sent to FGAddon.

Dedicated FGAddon branch

In the examples above, only a single branch was assumed in the repository. If interaction with a remote git repository or branching within the local git repository is desired, then a different strategy is required. The reason being that the branch that synchronises with FGAddon must preserve a linear history. This means only cherry-picking of the desired changes into that branch is allowed.

In this example, two branches will be set up in the local git repository:

fgaddon: This branch will be dedicated for FGAddon synchronisation and will preserve a linear history.
master: A master branch for aircraft development, allowing for mergers and other non-linear history operations.

Assuming a newly cloned repository, create the fgaddon branch with:

git branch fgaddon

And switch to that branch:

git checkout fgaddon

The FGAddon synchronisation can then be performed on this branch. To pull in the developments from the master branch, use cherry-picking to apply a sequentially ordered list of commit hashes:

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

To see the list of commits to be sent to FGAddon prior to dcommitting, type:

git log git-svn..HEAD

And to see the changes as a single diff:

git diff git-svn..HEAD

Synchronising

To send the changes to the remote FGAddon repository, firstly change to the dedicated fgaddon branch:

git checkout fgaddon

Make sure the local git-svn repository is up to date with all changes that have occurred in FGAddon:

git svn rebase

Then push or dcommit the changes to FGAddon with:

git svn dcommit

Deficiencies of git-svn

Advertència Performing a git-svn clone of the /trunk/ or entire repository is not recommended, as the entire repository history will be downloaded, resulting in a huge local repository, as well as putting a large strain on the FlightGear open source infrastructure.

It is important to understand that there are a number of operations in which git-svn is deficient. In many cases, the svn tools should be used instead.

Copying files between aircraft

Precaució Git-svn does not maintain the file copying history normally present in a Subversion repository.

The most important of these is the copying of content from other FGAddon aircraft. In this case you will need FGAddon commit access and a local svn copy of the repository. Firstly synchronise the repositories by dcommitting all changes back to FGAddon:

git svn dcommit

Then in the local svn repository, copy the file:

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

And commit the change:

svn ci

Back in the local git-svn repository, pull in the new files:

git svn rebase

Using the subversion tools avoids the FGAddon repository backend from significantly increasing in size, as svn copies are cheap.

Moving or renaming files

Precaució Git-svn does not always maintain the file moving or renaming history normally present in a Subversion repository.

This problem stems from the fact that svn history is more robust than that of git. The svn mv and git mv commands are not equivalent. The subversion command stores the move history directly in the repository whereas git does not (git instead uses heuristic methods to try to detect history, after the commit). The result of using git-svn is that often the move will not be detected and the FGAddon history will show one file or directory being deleted and another added. This also causes the repository backend to increase in size, whereas svn mv will not cause any significant size increase. If you wish to have a better historical record in the FGAddon repository and be considerate to the repository backend, it is recommended that you temporarily switch to the subversion tools. Firstly, synchronise the repositories:

git svn dcommit

Then in the local svn repository, move or rename the file:

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

And commit the change:

svn ci

Back in the local git-svn repository, pull in the changes with:

git svn rebase

Copying files within one aircraft

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

Subversion properties

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

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

Protocols other than svn+ssh

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

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

and

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

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

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

FGAddon development concepts

New aircraft

To add a new aircraft to the FGAddon repository, the SVN tools are required. If you encounter svn:mime-type property problems when adding a new aircraft, see the mime-type problems section for how to resolve the issue. Or if you have a svn:executable property problem, see the executable flag problem section.

svn import

Advertència The svn import command described herein will send all contents of the specified directory directly into FGAddon without warning and without a way to cancel the operation. Therefore special care must be taken when specifying the directory to upload into FGAddon, as well as the target FGAddon directory. See the svn add section below for a safer way to add a new aircraft.

The svn import command is the easiest method to use and does not require a local copy of the repository to be checked out. To start:

Create an empty local aircraft directory.
Copy the aircraft files into this directory.
Carefully check all files to make sure there are no hidden or temporary files that should not be uploaded to FGAddon.

Assuming the Dead Simple Human Powered Airplane (DaSH PA or "DaSH") aircraft as an example, located in the DaSH/ directory, on the command line run:

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

Where <username> is the SourceForge user name. This will add all the files into FGAddon with commit log message with the summary line Initial import of the DaSH human powered aircraft., followed by a blank line, and then a detailed description pointing to the original location or discussion of the aircraft. To see if the aircraft has been successfully added to the repository:

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

Or visit the FGAddon web interface. The aircraft can then be checked out as described in the Development scenarios section.

svn add

If a local copy of the FGAddon trunk is present, then the svn add command can be used instead. This is far safer than the svn import command, as the change can be double checked before committing. In the Aircraft/ directory of the local repository, create the DaSH/ directory. This can either be empty or contain all files of the initial aircraft. Then on the command line, add the aircraft to the local repository:

svn add DaSH/

Then double check the changes prior to committing:

svn st

And send the changes to FGAddon with:

svn ci

An editor, often vi^[9], will open and the commit message can be composed. Alternatively the commit log message can be specified on the command line with:

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

Commit blocking by pre-commit hooks

Sometimes when committing to FGAddon, the commit will be blocked the following will be printed out:

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

This is due to the presence of two repository pre-commit hook scripts which check the quality of the commit, blocking it if a text file is set to a binary file mime-type or if the executable flag is set. These scripts are simply to protect the repository and to keep it clean.

Mime-type problems

Sometimes when attempting to commit files to FGAddon using the SVN tools, the commit will be blocked with the following 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'

Despite messages about adding or sending files, no change will have occurred in the FGAddon repository. This message is created by a repository pre-commit hook script which checks if the Subversion svn:mime-type property is set on a list of known text files and, if the mime-type is set to a binary format, the commit is blocked. The reason for this block is to protect the repository. Newer SVN clients rely on a 3rd party library known as libmagic which will detect the aircraft XML files as the binary mime-type of application/xml. The result is that the XML files are treated as binary files in the repository. This behaviour is completely undesirable, as changes cannot be followed on the flightgear-fgaddon-commitlogs mailing list or in the repository history, and the size of the commits become orders of magnitude larger. Therefore this buggy behaviour has been blocked for the protection of the FlightGear project. To remove the problem, follow the instructions in the message and, using the command line tools, type:

svn propdel svn:mime-type <file_name>

Repeat this for each text file listed in the error message. Then commit again, using the commit message saved in the svn-commit.tmp file. The message file name will be reported in the commit failure message, but check its contents first:

cat svn-commit.tmp

And reperform the commit:

svn ci -F svn-commit.tmp

Subversion config file

The automatic property setting of svn:mime-type can be controlled by modifying the Subversion config file. Firstly in the [miscellany] section, make sure that the auto-properties are turned on:

enable-auto-props = yes

Then in the [auto-props] section, add:

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

These are all the text files that the hook script will check that the mime-type is set to a text format, though new text files will likely be added in the future. These additions can either be to the user configuration file located at ~/.subversion/config (or %USERPROFILE%\AppData\Roaming\Subversion\config in Windows) or, if a user configuration file is not set, to the global configuration file at /etc/subversion/config (or %APPDATA%\Subversion\config in Windows).

Executable flag

Another blocking message when attempting to commit files to FGAddon using the SVN tools 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'

This will probably only be seen on Mac OS X and GNU/Linux systems. This message is printed by a pre-commit repository hook script that checks if the Subversion svn:executable property is set and, if so, the commit is blocked. This is a security measure, as no aircraft files should be executable. To remove the problem, follow the instructions in the message and, using the command line tools, type:

svn propdel svn:executable -R

Then commit again, using the commit message saved in the svn-commit.tmp file. The message file name will be reported in the commit failure message, but check its contents first:

cat svn-commit.tmp

And the reperform the commit:

svn ci -F svn-commit.tmp

Binary diffs

Advertència The incorrect setting or absence of the mime-type property on a binary file will result in a binary diff.

When looking at the output of svn diff (or git diff if you are using git-svn) as well as when reading messages from the FGAddon commitlog mailing list, you may see a large number of unrecognisable characters. This is the result of what is known as a binary diff, showing the binary file differences as if it were text. Although this is not a issue for the operation of the repository, the situation is an aesthetic problem which makes it more difficult to perform a review of the changes.

To fix the problem, firstly the binary files with the svn:mime-type property missing need to be identified. The following subversion command can be used:

svn propget svn:mime-type <file_name>

As it can be tedious checking each file individually, the following Python script simplifies and automates the process to identify all binary files with a mime-type issue:

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

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

#! /usr/bin/env python

from os import getcwd, walk
from os.path import join, splitext
from re import search
from subprocess import PIPE, Popen


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

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

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

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

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

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

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

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

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

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

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

Fixing the problem

As git-svn cannot set or change the svn:mime-type property, a svn checkout copy of the aircraft is required. The property can then be set to the default Subversion binary mime-type with:

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

Alternatively, the following set of shell commands can be used to automate the process:

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

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

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

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

SourceForge developer services

The FlightGear project is hosted on the SourceForge open source infrastructure. This developer services section will highlight some of the useful tools you can take advantage of. SourceForge consists of two categories of services:

Project infrastructure: The FlightGear project uses the project services of SourceForge. These services are for standalone software projects.
Developer infrastructure: These are services available to anyone with a SourceForge account, and are available via your SourceForge homepage and accessible to all. This includes being able to create multiple version control repositories (svn, git, hg), wikis, forums, development teams, blogs, and ticket trackers (for bugs, support requests, tasks, etc.).

Rather than creating a new project, any development for the FlightGear project should be based on the developer infrastructure.

Developer git repository

To set up your own remote git repository, here for developing the FGAddon fkdr1 aircraft:

On your profile page at https://sourceforge.net/u/<username>/profile/, go to Admin -> Add New -> Git.
Set label to fkdr1 FGAddon git-svn repository.
Set the code path to code-fkdr1. The code-* prefix is to differentiate this from the forum-*, wiki-*, and other directories.

The repository will be located at https://sourceforge.net/u/<username>/code-fkdr1/ci/master/tree/.

Development teams

If you and a group of friends would like to privately develop one of the FGAddon aircraft as a team, assuming that the you have contacted the original aircraft authors and the aircraft is not actively being developed, then you should create a SourceForge development team. A team leader should be appointed to set this up under their SourceForge account. Assuming you wish to develop the "ornithopter" aircraft, the steps are:

Go to Personal tools -> Admin.
Click on User Permissions.
Click on Add a new group at the bottom.
Set the name to ornithopter, and save.
Click on Add in the ornithopter group and add the SourceForge names of all your team members.

After setting up a private repository in the team leader's account, as described below, then the development team should be set up for the repository.

Go to the repository under your SourceForge account.
Click on Admin - <repository name>, then select Permissions.
In the Write section, remove Developer and add ornithopter.
Click on Save.

The development team will then have commit access to the private repository.

Team communications

To help with team development, the SourceForge infrastructure allows for multiple dedicated discussion forums to be created. This can either be within a SourceForge project or under a SourceForge users homepage. This allows the team leader to create a forum dedicated solely to the development of the aircraft of interest. Continuing with the ornithopter example, the steps for the team leader are simple:

On your profile page at https://sourceforge.net/u/<username>/profile/, go to Personal tools -> Admin.
Click on the Tools option in the left hand menu.
Click on Discussion in the Click to install section.
Change the label to Ornithopter forum, and the path to forum-ornithopter, for example. The forum-* prefix is to differentiate this from the code-*, wiki-*, and other directories.
Click on Save.

More details are given on the SourceForge Discussion documentation.

Development scenarios

Individual developer

Nota Development scenario: You are an individual developer and will use the native Subversion tools.

This is by far the simplest development scenario and should be used in most cases. If you are using the command line Subversion client, you can checkout an individual aircraft with:

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

Where <username> is your SourceForge user name. Alternatively you can checkout all aircraft with:

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

If you do not have commit access, type one of:

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

To use the new local svn repository, see the subversion instructions.

Individual developer (git-svn)

Nota Development scenario: You are an individual developer and will use the git-svn tools.

This is more complicated than using the native SVN tools, but can be useful without having FGAddon commit access, as multiple local commits can be made to be sent to the original aircraft authors or to the development mailing list/forum. To clone the aircraft of choice into a new git repository, type:

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

Where <username> is your infrastructure user name and <aircraft> is the directory name in the FGAddon repository. This is valid whether or not you have commit permissions.

To use the new local git repository, see the git-svn instructions and its deficiencies.

Upload to Sourceforge

To share the local developments, the changes can be uploaded to a remote git repository on the SourceForge infrastructure. For this, a developer git repository should first be set up under your SourceForge profile. Then add this as a remote:

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

And send the master branch where developments are located with:

git push --set-upstream origin master

The changes in the new repository will be visible via the web interface at https://sourceforge.net/u/<username>/code-<aircraft>/ci/master/tree/.

Sending external git repository changes into FGAddon

Nota Development scenario: You are an individual developer with FGAddon commit access and wish to transfer the commits in a remote git repository into FGAddon using a temporary local git repository.

Firstly clone the FGAddon aircraft into a local git-svn repository with:

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

This will create a new local git repository linked to FGAddon via git-svn. If the aircraft is new and not present in FGAddon, see the instructions for adding a new aircraft to FGAddon. Next, set up the remote git repository as a remote, and fetch it:

git remote add <name> <url>
git fetch

Where <url> is the URL of the remote git repository. Finally make an ordered list of all hashes of the commits to be sent into FGAddon, from earliest to latest, and cherry-pick them into the git-svn master branch:

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

Note that the git-svn local repository should only have a single master branch and only consist of cherry-picking. To see the changes queued for sending to FGAddon:

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

Then to send the changes to FGAddon, firstly pull in any remote changes, and send the commits:

git svn rebase
git svn dcommit

The temporary local repository can then be deleted.

Connecting an existing git repository to FGAddon

Nota Development scenario: You are an individual developer or team leader with FGAddon commit access and wish to connect a pre-existing remote git repository with FGAddon to send all changes back to FGAddon.

If a remote git repository containing a developed aircraft already exists, it is possible to connect it to the remote FGAddon repository using the git-svn tools. The following uses the dedicated FGAddon branch technique. Firstly, set up the bridge to FGAddon using git-svn in the per-aircraft repository:

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

Where <aircraft> is the aircraft directory name in FGAddon. Note that this step can be performed without commit access to FGAddon by using a read-only SVN URL instead, but then changes cannot be pushed back to FGAddon (dcommitting, as it is known in the git-svn terminology). However, this allows upstream FGAddon changes to be integrated into the remote git repository, thus making it easy to prepare changes for submission for FGAddon inclusion using patches sent to the mailing list or sent via other channels.

Now fetch the current state from the remote FGAddon repository:

git svn fetch

The downloaded SVN history is in the remote branch remotes/git-svn. To commit changes to SVN you need a local branch that tracks this remote branch. Create a local fgaddon branch that you will use to commit updates:

git branch fgaddon remotes/git-svn

After committing new stuff to the master branch, to push to FGAddon checkout the fgaddon branch and update it from SVN in case someone else has touched the aircraft in the remote FGAddon repository:

git checkout fgaddon
git svn rebase

Cherry-pick the new commits from master to fgaddon to preserve a linear history:

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

To see the changes queued for sending to FGAddon as either commits or a diff, type:

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

If everything looks ok, dcommit the local commits on the fgaddon branch to send them to the remote FGAddon SVN repository:

git svn dcommit

Switch back to the master branch for local development:

git checkout master

To get changes from upstream you can either just download them with

git svn fetch

or download them and rebase your fgaddon branch onto them:

git checkout fgaddon
git svn rebase

Team development

Nota Development scenario: All members of the team are acting as gatekeepers, and all commits are made directly to FGAddon, either using svn or git-svn.

The simplest way to work as a team is for each developer to either have a svn copy of FGAddon or a git-svn copy of FGAddon, and everyone commits directly to FGAddon. Communication and coordination between the team members can be performed using a team leader organised SourceForge forum or using the FlightGear forum. In this scenario, the team needs to take the initiative and everyone apply for FGAddon commit access.

Private team development (git-svn)

Nota Development scenario: One team leader is acting as the gatekeeper on a private git repository hosted on the in-house SourceForge infrastructure, using git-svn to push a fgaddon branch to FGAddon, with team members committing directly to the private git repository or making merge requests from their fork of the private repository.

To keep everything in-house, the entire operation will be based on the official infrastructure and remote repositories under each user's SourceForge (SF) profile. Note to the team leader - you must keep your git-svn history linear (meaning that a dedicated FGAddon branch should be created and changes manually cherry-picked into this branch). In the following, the ornithopter aircraft will be used as an example.

The team

Firstly, the entire team should sign up for SourceForge accounts.

Team leader

Private repository set up

These steps are to be taken by the team leader. In your SourceForge user profile, set up a git repository with the label Ornithopter FGAddon git-svn repository and code path code-ornithopter. Then create a empty local git repository:

$ mkdir ornithopter
$ cd ornithopter
$ git init

Link the empty repository to the ornithopter aircraft directory in the remote FGAddon repository and pull it in with:

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

Replace <username> with your SF user name. Set up a special git-svn branch for FGAddon gatekeeping and dcommitting changes back to the repository:

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

And pull in the ornithopter from FGAddon:

$ git svn rebase

To see the current local git-svn repository setup, type:

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

Then return to the master branch:

$ git checkout master

Finally, set up the remote git repository as a remote:

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

And send the master branch to the remote git repository:

$ git push -u origin master

To see the new set up:

$ git branch -vva
$ git remote -v

The repository will be located at https://sourceforge.net/u/<username>/code-ornithopter/ci/master/tree/. Note that the git-svn information stored in the .git/svn directory will not be pushed to remote SoureForge repository, and therefore the link back to FGAddon will only be present in the local copy of the team leader. The git-svn link can be re-established at a later point if necessary.

Team setup

Set up a dedicated development team and grant them access to the git-svn repository.

Pushing to FGAddon

Committing to FGAddon is for the local git repository of the team leader. History must be linear in the fgaddon branch, so cherry-picking is the way to go. This is from the Individual developer (git-svn) section. In the local git repository, switch to the fgaddon branch:

git checkout fgaddon

Pull in any changes which have occurred in FGAddon:

git svn rebase

To see the commits in the master branch which are not in the fgaddon branch, type one of:

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

Manually select the commits to be sent to FGAddon and cherry-pick them:

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

Or to cherry-pick a range of commits:

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

Then check what is to be sent:

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

Send the changes to FGAddon, send the git fgaddon branch changes to the remote git repository, and switch back to the master branch:

git svn dcommit
git push
git checkout master

Finally merge in the git svn commits with their new hashes from the fgaddon branch, and send it to the remote git repository:

git merge fgaddon
git push

Team members

Working with the repository

Each team member should make a clone of the private git repository:

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

Replace <username> with your SourceForge user name, and <username_leader> is the SourceForge user name of the team leader.

Forking and merge requests

Alternatively, each team member can fork the git repository under your SourceForge account:

Go to https://sourceforge.net/u/<username>/code-ornithopter/ci/master/tree/, where <username> is the SourceForge user name of the team leader.
Click on Fork.
Set the mount point to code-ornithopter and change the label as you wish.

Develop and push to your fork, then make merge requests by clicking on the Request Merge button.

Referències

↑ 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.
↑ 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.
↑ 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.
↑ 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".
↑ Curtis Olson (Sep 28, 2015). Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@. Published on the FlightGear forum.
↑ James Turner (May 20, 2010). [Flightgear-devel] Re: Flightgear git repositories (was Re: GIT or CVS - Confusion) Published on the flightgear-devel mailing list.
↑ Cedric Sodhi (Oct 18, 2011) [Flightgear-devel] FGData Split Completed - a.k.a Life after the Split Published on the flightgear-devel mailing list.
↑ FlightGear Policy Document and Roadmap, draft document.
↑ Vim documentation

[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 documentation

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

Ca/FGAddon

Història

Obtenint aeronaus

Preparació

Directori de FGAddon

Descàrrega

Command line

GUI clients and TortoiseSVN

Flying

Updates

Aircraft development

Contact the original aircraft authors

SourceForge account

Commit access

FGAddon commitlog mailing list

Version control tools

Subversion

Set up

Repository checkout

Information and history

Daily usage

Committing changes

Branching

Git-svn

Set up

Cloning a single aircraft

Information and history

Daily usage

Committing changes

Dedicated FGAddon branch

Synchronising

Deficiencies of git-svn

Copying files between aircraft

Moving or renaming files

Copying files within one aircraft

Subversion properties

Protocols other than svn+ssh

FGAddon development concepts

New aircraft

svn import

svn add

Commit blocking by pre-commit hooks

Mime-type problems

Subversion config file

Executable flag

Binary diffs

Fixing the problem

SourceForge developer services

Developer git repository

Development teams

Team communications

Development scenarios

Individual developer

Individual developer (git-svn)

Upload to Sourceforge

Sending external git repository changes into FGAddon

Connecting an existing git repository to FGAddon

Team development

Private team development (git-svn)

The team

Team leader

Private repository set up

Team setup

Pushing to FGAddon

Team members

Working with the repository

Forking and merge requests

Referències

Navigation menu

Search