From 20a13305bea9e29e93396a029212cfca4e2ba32e Mon Sep 17 00:00:00 2001 From: dennis Date: Fri, 22 Aug 2008 11:15:17 +0000 Subject: Readme's überarbeitet: E-Mails von der Mailingliste eingearbeitet. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit git-svn-id: https://svn.neo-layout.org@796 b9310e46-f624-0410-8ea1-cfbb3a30dc96 --- Subversion-Anleitung.txt | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'Subversion-Anleitung.txt') diff --git a/Subversion-Anleitung.txt b/Subversion-Anleitung.txt index 15f4663..ae5a800 100644 --- a/Subversion-Anleitung.txt +++ b/Subversion-Anleitung.txt @@ -99,13 +99,15 @@ Statt auschecken wie in Abschnitt 2.1 beschrieben: ------------------------------------------------------------------------------ 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: -• Bevor man beginnt, die eigene SVN-Kopie zu bearbeiten, sollte immer erst ein Update durchgeführt werden (insbesondere, wenn das letzte Auschecken schon länger her liegt). Dies vermeidet mögliche Konflikte. +• 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. • Es ist vorteilhaft, inhaltlich Zusammengehörendes auch gemeinsam zu committen, und Dinge, die voneinander unabhängig sind, auch einzeln einzuchecken. -• Die Änderungsbeschreibung sollte immer eingegeben werden. +• Die Änderungsbeschreibung sollte immer eingegeben werden und möglichst genau sein. • 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: …« • 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)« -• Größere Commits können auch aufgeteilt werden, wenn die Intention dazu aus den Änderungsbeschreibungen hervor geht. +• Größere Commits können auch aufgeteilt werden, wenn die Intention dazu aus den Änderungsbeschreibungen hervor geht. • 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. +• Änderungen an der Referenz sollten unbedingt vorher auf der Mailingliste besprochen bzw. ausdiskutiert werden. Unwesentlichen Änderungen sollten zumindestens auf der Liste erwähnt werden. • … ------------------------------------------------------------------------------ + -- cgit v1.2.3