Changes between Version 5 and Version 6 of Subversion-Anleitung


Ignore:
Timestamp:
12/10/08 12:02:44 (18 years ago)
Author:
anonymous
Comment:

fertig

Legend:

Unmodified
Added
Removed
Modified

  • Subversion-Anleitung

    v5 v6  
    2626Angenommen ich möchte Neo in das Verzeichnis ''$VERZEICHNIS/$NEO'' runterladen:
    2727{{{
    28   cd $VERZEICHNIS
    29   svn checkout https://svn.neo-layout.org $NEO
     28cd $VERZEICHNIS
     29svn checkout https://svn.neo-layout.org $NEO
    3030}}}
    3131''$REPOSITORY_HOME'' ist dann ''$VERZEICHNIS/$NEO''
    … …  
    3333=== Das Repository auf meinem Rechner auf den neuesten Stand bringen ===
    3434{{{
    35   cd $REPOSITORY_HOME
    36   svn update
     35cd $REPOSITORY_HOME
     36svn update
    3737}}}
    3838
    3939=== Dateien im Repository ändern ===
    40 Einfach die Datei ändern und weiter geht’s mit Abschnitt 2.7. Allerdings bitte die [wiki:Stilregeln] für das Editieren von Dateien beachten.
     40Einfach die Datei ändern und weiter geht’s mit dem Abschnitt [wiki:Subversion-Anleitung#ÄnderungeninsRepositoryhochladen Änderungen ins Repository hochladen]. Allerdings bitte die [wiki:Stilregeln] für das Editieren von Dateien beachten.
    4141
    42 ------------------------------------------------------------------------------
    43 2.4 Dem Repository neue Dateien hinzufügen
     42=== Dem Repository neue Dateien hinzufügen ===
     43Nachdem man die Datei in der lokalen Repositorykopie erstellt hat:
     44{{{
     45svn add $DATEI
     46}}}
     47Weiter mit dem Abschnitt [wiki:Subversion-Anleitung#ÄnderungeninsRepositoryhochladen Änderungen ins Repository hochladen].
    4448
    45 Nachdem man die Datei in der lokalen Repositorykopie erstellt hat:
    46   svn add $DATEI
    47 weiter mit Abschnitt 2.7
     49=== Dateien im Repository umbenennen ===
     50{{{
     51svn mv $DATEI_ALT $DATEI_NEU
     52}}}
     53Weiter mit dem Abschnitt [wiki:Subversion-Anleitung#ÄnderungeninsRepositoryhochladen Änderungen ins Repository hochladen].
    4854
    49 ------------------------------------------------------------------------------
    50 2.5 Dateien im Repository umbenennen
     55=== Dateien aus dem Repository löschen ===
     56{{{
     57svn rm $DATEI
     58}}}
     59Weiter mit dem Abschnitt [wiki:Subversion-Anleitung#ÄnderungeninsRepositoryhochladen Änderungen ins Repository hochladen].
    5160
    52   svn mv $DATEI_ALT $DATEI_NEU
    53 weiter mit Abschnitt 2.7
    54 
    55 ------------------------------------------------------------------------------
    56 2.6 Dateien aus dem Repository löschen
    57 
    58   svn rm $DATEI
    59 weiter mit Abschnitt 2.7
    60 
    61 ------------------------------------------------------------------------------
    6261=== Änderungen ins Repository hochladen ===
    6362{{{
    64   cd $REPOSITORY_HOME
    65   svn commit -m "$ÄNDERUNGSBESCHREIBUNG" --username $USER
     63cd $REPOSITORY_HOME
     64svn commit -m "$ÄNDERUNGSBESCHREIBUNG" --username $USER
    6665}}}
    6766
    6867Wenn man das Repository mit seinem Nutzernamen ausgecheckt hat,
    6968kann »--username $USER« weggelassen werden.
    70 Statt auschecken wie in Abschnitt 2.1 beschrieben:
     69Statt auszuchecken wie im Abschnitt [wiki:Subversion-Anleitung#DasRepositorylokalaufmeinemRechnerhaben Das Repository lokal auf meinem Rechner haben] beschrieben, dann dies hier:
    7170{{{
    72   cd $VERZEICHNIS_WO_NEO_REIN_SOLL
    73   svn checkout https://$USER@svn.neo-layout.org neo
     71cd $VERZEICHNIS_WO_NEO_REIN_SOLL
     72svn checkout https://$USER@svn.neo-layout.org neo
    7473}}}
    7574
    76 ------------------------------------------------------------------------------
    77 3. Ratschläge / »best practice«
    78 ------------------------------------------------------------------------------
     75== Ratschläge / »best practice« ==
    7976In 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:
    80 
    81 ‣ 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.
    82 
    83 ‣ Es ist vorteilhaft, inhaltlich Zusammengehörendes auch gemeinsam zu committen, und Dinge, die voneinander unabhängig sind, auch einzeln einzuchecken.
    84 
    85 ‣ Die Änderungsbeschreibung sollte immer eingegeben werden und möglichst genau sein.
    86 
    87 ‣ 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: …«
    88 
    89 ‣ 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)«
    90 
    91 ‣ Größere Commits können auch aufgeteilt werden, wenn die Intention dazu aus den Änderungsbeschreibungen hervor geht.
    92 
    93 ‣ 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.
    94 
    95 ‣ Änderungen an der Referenz sollten unbedingt vorher auf der Mailingliste besprochen bzw. ausdiskutiert werden. Unwesentliche Änderungen sollten zumindestens auf der Liste erwähnt werden.
     77 * 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.
     78 * Es ist vorteilhaft, inhaltlich Zusammengehörendes auch gemeinsam zu committen (hochzuladen), und Dinge, die voneinander unabhängig sind, auch einzeln einzuchecken.
     79 * Die Änderungsbeschreibung sollte immer eingegeben werden und möglichst genau sein.
     80 * 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: …«
     81 * 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)«
     82 * Größere Commits können auch aufgeteilt werden, wenn die Intention dazu aus den Änderungsbeschreibungen hervor geht.
     83 * 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.
     84 * Änderungen an der Referenz sollten unbedingt vorher auf der Mailingliste besprochen bzw. ausdiskutiert werden. Unwesentliche Änderungen sollten zumindestens auf der Liste erwähnt werden.
    9685
    9786