FGAddon: Difference between revisions

Jump to navigation Jump to search
1,550 bytes added ,  27 June 2016
→‎Deficiencies of git-svn: Mandate svn+ssh for git-svn clones, explain why.
(→‎Individual developer (git-svn): Always use svn+ssh, never https.)
(→‎Deficiencies of git-svn: Mandate svn+ssh for git-svn clones, explain why.)
Line 309: Line 309:
{{warning|Performing a <code>git-svn clone</code> of the <code>/trunk/</code> 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.}}
{{warning|Performing a <code>git-svn clone</code> of the <code>/trunk/</code> 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.}}


There are a number of operations in which git-svn is deficient and the svn tools should be used instead.
There are a number of operations in which git-svn is deficient and the svn tools should be used instead. Other deficiencies do not require the use of Subversion but contain gotchas.


==== Copying files between aircraft ====
==== Copying files between aircraft ====
Line 370: Line 370:


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.
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 ====
<code>git svn init</code> replicates the entire history of an aircraft into a local repository; as part of this process, it constructs a git commit id for every Subversion revision. The problem is that the git commit id depends on the protocol used to read from the Subversion repository; therefore:
{{#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.


== FGAddon development concepts ==
== FGAddon development concepts ==
41

edits

Navigation menu