De/FGAddon: Difference between revisions

Jump to navigation Jump to search
6,119 bytes added ,  4 September 2018
Line 303: Line 303:
=== Nachteile des git-svn ===
=== Nachteile des git-svn ===


==== Kopieren von Dateien zwischen Flugzeuge ====
{{warning|Es ist nicht empfohlen, einen <code>git-svn clone</code> des Verzeichnisstammes <code>/trunk/</code> oder des gesamten Repositoriums, durchzuführen. Dies führt dazu, dass der gesamte Repo-Verlauf heruntergeladen wird. Die Folge ist ein riesiges Repository und wirkt sich zudem nachteilig auf die Infrastruktur des FlightGear Repositoriums aus.}}
 
Es ist wichtig, zu verstehen dass git-svn zahlreiche Nachteile aufweise bzw. in einigen Bereich weniger effizient arbeiten kann. In den meisten Fällen ist es in solchen Situationen ratsam, stattdessen die "SVN Tools" zu verwenden.
 
==== Kopieren von Dateien zwischen Flugzeugen ====
 
{{caution|Git-svn verfügt über einen Verlauf der kopierten Dateien, wie er normalerweise in Suversion-Repositorien vorhanden ist!}}
 
Der wichtigste Schritt ist das Kopieren von anderen FGAddon Flugzeugen. In diesem Fall benötigst Du Commit-Berechtigungen für das FGAddon Repository sowie eine lokale Kopie desselben. Als erstes muss Du nun die Repositories sychronisieren, indem Du alle aktuellen Änderen mit einem "dcommit" zurück an FGAddon schickst:
<syntaxhighlight lang="bash">
git svn dcommit
</syntaxhighlight>
 
Anschließend kannst Du die gewünschte Datei im lokalen Repositorium kopieren:
<syntaxhighlight lang="bash">
svn cp Aircraft/<aircraft1>/<file_path1> Aircraft/<aircraft2>/<file_path2>
</syntaxhighlight>
 
Und die Änderungen durch einen Commit durchführen:
<syntaxhighlight lang="bash">
svn ci
</syntaxhighlight>
 
Zurück im lokalen git-svn Repositorium kannst Du nun alle notwendigen Dateien pullen:
<syntaxhighlight lang="bash">
git svn rebase
</syntaxhighlight>
 
Durch die Nnutzung der Subversion Tools kannst Du verhindern, dass das Backend des FGAddon Repositoriums zu stark anwächst. Mehr Informationen dazu findest Du hier (Englisch): [http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html#svn.branchmerge.using.create svn copies are cheap].


==== Verschieben oder Umbenennen von Dateien ====
==== Verschieben oder Umbenennen von Dateien ====
{{caution|Git-svn erzeugt nicht immer einen Verlauf für das Verschieben oder Umbenennen von Dateien, wie es normalerweise bei einem Subversion Repository der Fall ist.}}
This problem stems from the fact that svn history is more robust than that of git.  The <code>svn mv</code> and <code>git mv</code> 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 <code>svn mv</code> 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:
<syntaxhighlight lang="bash">
git svn dcommit
</syntaxhighlight>
Then in the local svn repository, move or rename the file:
<syntaxhighlight lang="bash">
svn mv Aircraft/<aircraft>/<file_path1> Aircraft/<aircraft>/<file_path2>
</syntaxhighlight>
And commit the change:
<syntaxhighlight lang="bash">
svn ci
</syntaxhighlight>
Back in the local git-svn repository, pull in the changes with:
<syntaxhighlight lang="bash">
git svn rebase
</syntaxhighlight>
==== Copying files within one aircraft ====
Just as the <code>svn mv</code> command stores the move information directly within the repository, so does <code>svn cp</code> 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 ====
{{caution|Git-svn currently only supports the <code>svn:executable</code> 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 <code>svn:mime-type</code> repository property.  However as git-svn cannot set this property when using the <code>git add</code> command, the result is that binary files will be treated as text.  Binary diffs will be seen when using <code>svn diff</code> or <code>git diff</code>, and a binary diff will be shown in the [[#FGAddon commitlog mailing list|FGAddon commitlog mailing list]] messages.  As this issue is not unique to git-svn, to work around this issue please see the [[#Binary diffs|binary diffs]] section.
==== Protocols other than svn+ssh ====
The command <code>git svn init</code> 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:
{{#tag:syntaxhighlight|
{{fgaddon source|cmd=git svn init|protocol=svn+ssh|login=<username>|type=svn|path=Aircraft/<aircraft>|full=1}}
| lang = "sh"
}}
and
{{#tag:syntaxhighlight|
{{fgaddon source|cmd=git svn init|protocol=https|type=svn|path=Aircraft/<aircraft>|full=1}}
| lang = "sh"
}}
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.


==== Kopieren von Dateien innerhalb eines Flugzeuges ====
==== Kopieren von Dateien innerhalb eines Flugzeuges ====
7

edits

Navigation menu