Redaktionell arbeiten wir z. B. Neuerungen in der Branchversion im Intranet ein. Nur absolute Basics werden in Vorversionen, dann i. d. R. in der Trunk-Version angepasst. Diese werden dann bis zum Branch durchgemerged. Durch Veröffentlichung des Servicepack 1 zu Version 20.21 Ende Juni 2021 wurde z. B. die Version 20.21.1 zur neuen Trunk-Version und die neue Branchversion 20.21.1 wurde eingerichtet. Optional: Eine Angabe der Kalenderwoche nach der Programmversion (letzer Upload von KW…) auf der Startseite könnte dem Anwender helfen, zu entscheiden, welche Informationen ggf. zusätzlich per Patchnotes zu berücksichtigen sind, wenn er eine aktuellere Version einsetzt.
Durch die Verwendung von TortoiseSVN (Subversion) werden bestimmte Dateien aus dem Wiki-Verzeichnis über Add
und Commit
gesichert. Aufgrund der Abfragen und den damit verbunden Merge-Prozessen ist eine bestimmte Abfolge im Umgang mit TortoiseSVN für die iX-Wiki-Varianten zu beachten. Hauptansprechpartner für die SVN-Konfiguration ist SMV.
Da innerhalb von DokuWiki, dem von iX-Wiki verwendeten Wikisystem, ebenfalls eine Versionskontrolle über das php-System operiert, ist zwischen Versionskonflikten in TortoiseSVN und Versionskonflikten in DokuWiki zu unterscheiden. Da wir nur bestimmte Dateien des DokuWikisystems in TortoiseSVN betrachten und nur für diese eine Versionkontrolle vorsehen, ist es möglich, dass spezielle DokuWikifunktionen hierdurch unterbrochen oder nicht optimal ausgeführt werden können. Solange diese Funktionen ebenfalls nur eine Wiki-interne Versionkontrolle betreffen, sehen wir das als unkritisch an. Im laufenden Betrieb sind bislang praktisch keine Versionskonflikte in Dokuwiki aufgetreten.
Welche Dateien sollten trunk/branch-spezifisch sein?
Für eine versionsspezifische Sicherung sind auf jeden Fall data\pages
, data\media
relevant zzgl. der Inhalte der Verzeichnisse conf
und lib
. Die Konfigurationsdateien aus dem Verzeichnis conf
sowie der Plugins lib\plugins
beinhalten ggf. individualisierte Daten, die ebenfalls gesichert werden müssen und im Zweifelsfall versionsspezifisch (trunk oder branch) sind. Wird z. B. ein Plugin im Trunk installiert und liefert spezifische Codes im Seitentext, können diese Codes in der Branch-Variante nur dann sicher interpretiert werden, wenn das gleiche Plugin dort ebenfalls mit der gleichen Konfiguration eingerichtet ist! Daher ist die Liste der verwendeten Plugins sinnvoll, um den Überblick über die das DokuWiki ergänzenden Features zu behalten. Plugins sollten nach einer Testphase möglichst immer in beiden Versionen parallel installiert werden.
TortoiseSVN-Eigenschaften (Beispiele)
Hier kann man sehen, welche Dateien oder Pfade beim SVN-Abgleich ignoriert werden. Diese werden demnach in den einzelnen Versionen per Installation oder über manuelle Prozesse eingepflegt und werden nicht gemergt.
Bei Mergekonflikten in der Error-E-Mail auf Antworten
klicken und in dem Mail-Editor dann mit Strg + F
nach „conflict(s)“ suchen. Dort sind dann die Dateien benannt, welche konfliktbehaftet sind.
Nachfolgende Infos wurde aus der SVN-Hilfe entnommen…
Ab und an werden Sie einen Konflikt erhalten, wenn Sie Ihre Arbeitskopie aktualisieren oder zu einer anderen URL wechseln. Es gibt zwei Arten von Konflikten:
Ein Konflikt tritt dann auf, wenn mehrere Personen die gleichen Zeilen in einer Datei verändert haben. Da Subversion nichts über Ihr Projekt weiß, überlässt es in solchen Fällen Ihnen, den Konflikt aufzulösen. Die sich in Konflikt befindlichen Bereiche sind in der Resolve-Ansicht folgendermaßen markiert:
<<<<<<< Dateiname Ihre Änderungen ======= Code aus dem Projektarchiv >>>>>>> Revision
Außerdem werden für jede Datei in Konflikt drei weitere Dateien in Ihrem Verzeichnis erstellt:
Dies ist die Datei, so wie Sie war, bevor Sie Ihre Arbeitskopie aktualisierten. Das heißt, es ist Ihre eigene Originaldatei inklusive der Änderungen, die Sie selbst vorgenommen haben.
Dies ist die Datei, wie Sie ursprünglich war, ohne jegliche Änderungen, auch ohne die Änderungen, die Sie selbst an der Datei vorgenommen haben.
Dies ist die Datei, wie sie im Projektarchiv gerade aktuell ist, d. h., diese Datei hat die Änderungen von den anderen Mitarbeitern bereits integriert, jedoch noch nicht die Ihren.
Sie können entweder einen externen Konflikteditor per TortoiseSVN → Konflikt bearbeiten
aufrufen oder Sie können den Konflikt mit einem beliebigen Texteditor manuell auflösen. Sie müssen entscheiden, wie der Code aussehen soll, die notwendigen Änderungen vornehmen und die Datei speichern. Mit einem Konflikteditor wie TortoiseMerge oder einem der anderen beliebten Programme ist das im allgemeinen einfacher, da diese die betroffenen Dateien normalerweise in einer Drei-Fenster-Sicht anzeigen und Sie sich keine Gedanken über die Konfliktmarken machen müssen. Wenn Sie einen Texteditor verwenden, müssen sie manuell nach Zeilen suchen, die mit «««< beginnen.
Anschließend müssen Sie Subversion noch mitteilen, dass Sie den Konflikt aufgelöst haben. Dies geschieht mit dem Befehl TortoiseSVN → Konflikt aufgelöst
. Bitte beachten Sie, dass dieser Befehl nicht den Konflikt selbst löst, sondern nur Subversion mitteilt, dass Sie selbst den Konflikt bereits gelöst haben. Der Befehl macht nichts weiter als die drei zusätzlich erstellten Dateien filename.ext.mine
und filename.ext.r*
zu löschen, damit sie Ihre Änderungen in das Projektarchiv übertragen können.
Wenn ein Konflikt zwischen Binärdaten besteht, versucht Subversion nicht, die Daten selbst zusammenzuführen. Die lokale Datei bleibt unverändert (exakt so, wie sie Ihrer letzten Änderung entspricht) und Sie erhalten Dateiname.ext.r*
Dateien. Wenn Sie Ihre eigenen Änderungen verwerfen wollen, tun Sie das mit dem Befehl Rückgängig
. Wenn Sie Ihre Version beibehalten und die Version im Projektarchiv überschreiben wollen, verwenden Sie den Befehl Konflikt aufgelöst
und übertragen anschließend die Daten ins Projektarchiv.
Sie können den Befehl Konflikt aufgelöst
für mehrere Dateien verwenden, indem Sie den übergeordneten Ordner markieren und TortoiseSVN → Konflikt aufgelöst…
aus dem Kontextmenü wählen. Dies öffnet einen Auswahldialog, in dem alle konfliktbehafteten Dateien aufgelistet sind. Wählen Sie die Dateien, die Sie als aufgelöst markieren wollen.
Ein Eigenschaftskonflikt entsteht dann, wenn zwei oder mehr Entwickler dieselbe SVN-Eigenschaft verändert haben. Wie bei Dateikonflikten können nur Entwickler solche Konflikte auflösen.
Wenn eine der Änderungen die andere überschreiben soll, wählen Sie entweder Mit der lokalen Eigenschaft auflösen
oder Mit der Eigenschaft aus dem Projektarchiv auflösen
. Wenn die Änderungen zusammengeführt werden müssen, wählen Sie Revisionseigenschaft bearbeiten
, tragen dort den gewünschten Wert ein und markieren den Konflikt als aufgelöst.
Ein Baumkonflikt entsteht, wenn ein Entwickler eine Datei oder einen Ordner umbenannt, verschoben oder gelöscht hat, den ein anderer Entwickler ebenfalls umbenannt, verschoben, gelöscht oder bearbeitet hat. Es gibt verschiedene Ursachen für Baumkonflikte und alle erfordern unterschiedliche Vorgehensweisen, um den Konflikt aufzulösen.
Wenn eine Datei in Subversion lokal gelöscht wird, wird sie auch aus dem lokalen Dateisystem gelöscht. Das bedeutet, dass kein überlagertes Symbol angezeigt werden kann, wenn sie Teil eines Baumkonfliktes ist und dass Sie den Konflikt nicht mit Hilfe eines Rechtsklicks auflösen können. Verwenden Sie stattdessen den Auf Änderungen prüfen
Dialog, um den Konflikt bearbeiten
zu können.
TortoiseSVN kann dabei helfen, Änderungen zusammenzuführen, aber es kann zusätzliche Arbeit erforderlich sein, um die Konflikte aufzulösen. Bedenken Sie, dass nach eine Aktualisierung die BASE der Arbeitskopie dem Inhalt des Projektarchivs entspricht. Wenn Sie eine Änderung nach dem Aktualisieren rückgängig machen, wird das Objekt in den Status des Projektarchivs zurückversetzt und nicht in den Zustand, in dem Sie begonnen haben, Ihre eigenen Änderungen durchzuführen. </nodisp>