Changeset 895
- Timestamp:
- 09/16/08 13:11:28 (5 years ago)
- Files:
-
- 1 modified
-
Subversion-Anleitung.txt (modified) (5 diffs)
Legend:
- Unmodified
- Added
- Removed
-
Subversion-Anleitung.txt
r894 r895 39 39 1.3 Terminologie 40 40 41 $REPOSITORY_HOME 42 Das Verzeichnis in dem das ausgecheckte Repository liegt 41 $REPOSITORY_HOME – Das Verzeichnis in dem das ausgecheckte Repository liegt 43 42 44 43 ------------------------------------------------------------------------------ … … 47 46 2.1 Das Repository lokal auf meinem Rechner haben 48 47 49 Angenommen ich möchte Neo in das Verzeichnis $VERZEICHNIS/$NEOrunterladen:48 Angenommen ich möchte Neo in das Verzeichnis »$VERZEICHNIS/$NEO« runterladen: 50 49 51 50 cd $VERZEICHNIS … … 63 62 2.3 Dateien im Repository ändern 64 63 65 Einfach die Datei ändern und weiter geht s mit Abschnitt 2.7.64 Einfach die Datei ändern und weiter geht’s mit Abschnitt 2.7. 66 65 67 66 ------------------------------------------------------------------------------ … … 91 90 92 91 Wenn man das Repository mit seinem Nutzernamen ausgecheckt hat, 93 kann --username $USERweggelassen werden.92 kann »--username $USER« weggelassen werden. 94 93 Statt auschecken wie in Abschnitt 2.1 beschrieben: 95 94 cd $VERZEICHNIS_WO_NEO_REIN_SOLL … … 101 100 In diesem Abschnitt geht es weniger um technische Fragen, sondern eher darum, wie man sinnvoll/empfohlenerweise mit einem SVN arbeiten sollte. Diese Ratschläge haben sich in der Praxis als sinnvoll erwiesen: 102 101 103 Bevor man beginnt, die eigene SVN-Kopie zu bearbeiten, sollte immer erst ein Update durchgeführt werden (insbesondere, wenn das letzte Aus-checken schon länger her liegt). Dies vermeidet mögliche Konflikte.102 ‣ Bevor man beginnt, die eigene SVN-Kopie zu bearbeiten, sollte immer erst ein Update durchgeführt werden (insbesondere, wenn das letzte Aus-checken schon länger her liegt). Dies vermeidet mögliche Konflikte. 104 103 105 Es ist vorteilhaft, inhaltlich Zusammengehörendes auch gemeinsam zu committen, und Dinge, die voneinander unabhängig sind, auch einzeln einzuchecken.104 ‣ Es ist vorteilhaft, inhaltlich Zusammengehörendes auch gemeinsam zu committen, und Dinge, die voneinander unabhängig sind, auch einzeln einzuchecken. 106 105 107 Die Änderungsbeschreibung sollte immer eingegeben werden und möglichst genau sein.106 ‣ Die Änderungsbeschreibung sollte immer eingegeben werden und möglichst genau sein. 108 107 109 Längere Änderungsbeschreibungen sollten mit einer kurzen Zusammenfassung der Form »[Adjektiv] Subjekt Prädikat: 110 « begonnen werden, etwa »Neues Feature: 111 «, »Caps-Lock-Fehler behoben: 112 «, »Dokumentation ergänzt: 113 « 108 ‣ Längere Änderungsbeschreibungen sollten mit einer kurzen Zusammenfassung der Form »[Adjektiv] Subjekt Prädikat: …« begonnen werden, etwa »Neues Feature: …«, »Caps-Lock-Fehler behoben: …«, »Dokumentation ergänzt: …« 114 109 115 Inhaltliche (bzw. »programmiertechnische«) Änderungen (oder Fehlerkorrekturen) sollten unabhängig von ästhetischen Korrekturen (wie Einrückungen oder der Korrektur von Rechtschreibfehlern) eingecheckt werden. Mögliche Änderungsbeschreibungen wären etwa: [Revision 698:] »Doku erweitert: Wie man NEO auf dem C64 installieren kann«, [Revision 699:] »Formatierung korrigiert: Leere Zeilen entfernt, Einrückung angeglichen (r698)«110 ‣ Inhaltliche (bzw. »programmiertechnische«) Änderungen (oder Fehlerkorrekturen) sollten unabhängig von ästhetischen Korrekturen (wie Einrückungen oder der Korrektur von Rechtschreibfehlern) eingecheckt werden. Mögliche Änderungsbeschreibungen wären etwa: [Revision 698:] »Doku erweitert: Wie man NEO auf dem C64 installieren kann«, [Revision 699:] »Formatierung korrigiert: Leere Zeilen entfernt, Einrückung angeglichen (r698)« 116 111 117 Größere Commits können auch aufgeteilt werden, wenn die Intention dazu aus den Änderungsbeschreibungen hervor geht.112 ‣ Größere Commits können auch aufgeteilt werden, wenn die Intention dazu aus den Änderungsbeschreibungen hervor geht. 118 113 119 Wenn man Angst um kostbare Änderungen durch einen Headcrash während einer intensiven Change-Session hat, muss man einen Branch für den Zeitraum der Änderungen eröffnen.114 ‣ Wenn man Angst um kostbare Änderungen durch einen Headcrash während einer intensiven Change-Session hat, muss man einen Branch für den Zeitraum der Änderungen eröffnen. 120 115 121 Änderungen an der Referenz sollten unbedingt vorher auf der Mailingliste besprochen bzw. ausdiskutiert werden. Unwesentliche Änderungen sollten zumindestens auf der Liste erwähnt werden.116 ‣ Änderungen an der Referenz sollten unbedingt vorher auf der Mailingliste besprochen bzw. ausdiskutiert werden. Unwesentliche Änderungen sollten zumindestens auf der Liste erwähnt werden. 122 117 ------------------------------------------------------------------------------ 123 118
