You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: book/09-git-and-other-scms/sections/import-svn.asc
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,10 +3,10 @@
3
3
(((Subversion)))
4
4
(((Importing, from Subversion)))
5
5
Wenn Sie den vorherigen Abschnitt über die Verwendung von `git svn` gelesen haben, können Sie die Anweisungen zu `git svn clone` leicht dazu benutzen, um ein Repository zu klonen. Beenden Sie dann die Verwendung des Subversion-Servers, pushen Sie zu einem neuen Git-Server und starten Sie dessen Nutzung.
6
-
Der Verlauf kann in diesem Fall schnellstens aus dem Subversion-Server gezogen werden (was einige Zeit in Anspruch nehmen kann).
6
+
Der Verlauf kann in diesem Fall aus dem Subversion-Server gezogen werden (was einige Zeit in Anspruch nehmen kann - abhängig von der Geschwindigkeit, mit der Ihr SVN-Server die Historie ausliefern kann).
7
7
8
8
Allerdings ist der Import nicht perfekt. Da er aber so lange dauert, können Sie ihn genauso gut auch richtig machen.
9
-
Das erste Problem ist die Autoreninformation.
9
+
Das erste Problem sind die Autoreninformationen.
10
10
In Subversion hat jede Person, die einen Commit durchführt, auch einen Benutzer-Account auf dem System, der in den Commit-Informationen erfasst wird.
11
11
Die Beispiele im vorherigen Abschnitt zeigen an einigen Stellen `schacon`, wie z.B. der `blame` Output und das `git svn log`.
12
12
Wenn Sie diese auf bessere Git-Autorendaten abbilden möchten, benötigen Sie eine Zuordnung der Subversion-Benutzer zu den Git-Autoren.
@@ -69,7 +69,7 @@ Date: Sun May 3 00:12:22 2009 +0000
69
69
be05-5f7a86268029
70
70
----
71
71
72
-
sehen sie jetzt so aus:
72
+
sehen diese jetzt so aus:
73
73
74
74
[source]
75
75
----
@@ -93,7 +93,7 @@ Damit die Tags zu richtigen Git-Tags werden, starten Sie:
93
93
$ for t in $(git for-each-ref --format='%(refname:short)' refs/remotes/tags); do git tag ${t/tags\//} $t && git branch -D -r $t; done
94
94
----
95
95
96
-
Dabei werden die Referenzen, die Remote-Branches waren und mit `refs/remotes/tags/` begonnen haben, genommen und zu richtigen (leichten) Tags gemacht.
96
+
Dabei werden die Referenzen, die Remote-Branches waren und mit `refs/remotes/tags/` begonnen haben zu richtigen (leichten) Tags gemacht.
97
97
98
98
Als nächstes verschieben Sie den Rest der Referenzen unter `refs/remotes` in lokale Branches:
99
99
@@ -104,8 +104,8 @@ $ for b in $(git for-each-ref --format='%(refname:short)' refs/remotes); do git
104
104
105
105
Es kann vorkommen, dass Sie einige zusätzliche Branches sehen, die durch `@xxx` ergänzt sind (wobei xxx eine Zahl ist), während Sie in Subversion nur einen Branch sehen.
106
106
Es handelt sich hierbei um eine Subversion-Funktion mit der Bezeichnung „peg-revisions“, für die Git einfach kein syntaktisches Gegenstück hat.
107
-
Daher fügt `git svn` einfach die svn-Versionsnummer zum Branch-Namen hinzu, genau so, wie Sie es in svn geschrieben hätten, um die peg-Revision dieses Branchs anzusprechen.
108
-
Wenn Sie sich nicht mehr um die peg-Revisionen sorgen wollen, entfernen Sie sie einfach:
107
+
Daher fügt `git svn` einfach die SVN-Versionsnummer zum Branch-Namen hinzu, genau so, wie Sie es in SVN geschrieben hätten, um die peg-Revision dieses Branchs anzusprechen.
108
+
Wenn Sie sich nicht mehr um die peg-Revisionen sorgen wollen, entfernen Sie diese einfach:
0 commit comments