tl; dr:
git svn schafft diese "@" - Zweig, wenn ein Zweig (oder Tag) wurde für ein Unterverzeichnis erstellt (oder für ein anderes Verzeichnis, das nicht durch git-svn verfolgt wird). Es wird immer auch einen "regulären" Zweig mit demselben Namen geben, aber ohne das Suffix "@". Der "@" - Zweig existiert nur als Verzweigungspunkt für den regulären Zweig.
Hinweis: Ich habe einen Patch dafür eingereicht; Eine bearbeitete Version dieser Erklärung ist jetzt Teil der offiziellen Hilfeseite git svn als neuer Abschnitt "HANDLING VON SVN-ZWEIGEN" (seit Git 1.8.1).
In Subversion, Zweige und Tags sind nur Kopien eines Verzeichnisbaumes, so ist es möglich (wenn auch in der Regel abgeraten) einen Zweig von einem Verzeichnis zu erstellen, die nicht selbst ein Zweig (oder Stamm) ist. Zum Beispiel, indem man/trunk/foo nach/branches/bar kopiert, anstatt sozusagen/trunk (sozusagen einen "Unterverzeichniszweig") zu kopieren, oder indem man ein Verzeichnis kopiert, das außerhalb der Struktur trunk/tags/branches liegt möglich in SVN).
In git ist jedoch immer ein Zweig für den gesamten Repo, Unterverzeichniszweige existieren nicht. git svn verwendet daher eine Problemumgehung. Wenn ein Zweig erkannt wird, der aus einem Verzeichnis kopiert wurde, das nicht selbst von git-svn als Zweig verfolgt wird, wird ein neuer Verlauf erstellt. Zum Beispiel für ein Unterverzeichnis Zweig, in dem/trunk/foo/branches/bar in r1234 kopiert wird, wird es erstellen:
- Ein neues git commit für jede SVN Revision von r1233 auf rückwärts (beachten Sie die Anzahl der ist letzte Revision, bevor die Filiale erstellt wurde). Die Bäume dieser Commits enthalten nur das Unterverzeichnis, das verzweigt wurde. Für jede Revision von r1233 rückwärts gibt es normalerweise zwei Git-Commits, eins mit dem gesamten Baum (erstellt, wenn git-svn den Verlauf von
trunk verarbeitet hat) und die neuen.
- Ein Dummy-Zweig mit dem Namen "bar @ 1233" (Zweigname @ revision), der auf das von r1233 oben erstellte Commit verweist.
- Ein Commit von r1234, dem Commit, das den Zweig erstellt hat. Dieses Commit wird den Zweig oben als seinen (einzigen) Vorfahren haben.
- Ein Zweig namens "bar", der auf das zweite Commit verweist.
Auf diese Weise für das Unterverzeichnis Zweig Bar, erhalten Sie zwei Niederlassungen in git
- bar @ 1233, die den Zustand des Repository darstellt, die die Niederlassung von
- bar erstellt wurde, welches den Zweig darstellt
Ich bin nicht ganz sicher, warum dieser Dummy-Zweig erstellt wird. Ich denke, es wird gemacht, um die Information darüber darzustellen, von welcher Revision die Zweigstelle abzweigt, und um eine vollständige Geschichte für die Zweigstelle zu haben.
Man beachte, daß dieser ganze Mechanismus durch Verwendung des Flag --no-follow-parent abgeschaltet werden kann. In diesem Fall führt jeder SVN-Zweig zu einem Git-Zweig mit nur den Commits aus dem SVN-Zweigverzeichnis. Jeder Zweig wird nicht mit dem Rest des Verlaufs verknüpft und hat sein eigenes Root-Commit, das dem ersten Commit in dem Zweig entspricht.
Ich habe es wirklich schwer zu finden, woher diese Benennung stammt, aber es sieht so aus, als ob diese Zweige aus SVN-Commits erstellt werden, die nicht mehr vom svn-Zweig (oder -Tag) referenziert werden. Wie nicht referenzierte Commits in Git, außer dass es möglich war, den Branch-Namen für das Commit wiederherzustellen. – fork0
@ fork0: Danke für die Antwort. Aber ich verstehe nicht klar, wie unreferenzierte Commits in SVN vorhanden sein können. Wie können Referenzen verloren gehen? Kannst du deine Gedanken dazu teilen? – crankparty
Ich weiß es nicht. Vielleicht hat der Betreuer des SVN-Repositorys sie nie bereinigt (oder SVN hat überhaupt keine Fähigkeit?). Ich wollte nicht sagen, dass die Referenzen verloren gegangen sind, sondern jemand hat gerade angefangen, von einem früheren Punkt in der Geschichte auszugehen. – fork0