Entwicklerhandbuch/Delixs-SVN

Diese Seite ist momentan eine Baustelle im Zustand: 2

• 0

  Bearbeitung noch offen

• 1

  Bearbeitung übernommen

• 2

  Bearbeitung abgeschlossen

• 3

  Korrekturlesen abgeschlossen

• 4

  Fremdkorrektur abgeschlossen

Wird bearbeitet von: Hjg

Hilfe zum Bearbeitungsstatus: Hilfe:Status eines Artikels

Einführung

In dieser Anleitung soll gezeigt werden, wie man debiankonforme Pakete in das Delixs-SVN-Repository einbringt und dort weiterentwickelt.

Bislang hat jeder Entwickler seine Delixs-Pakete einzeln für sich erstellt und das Ergbnis seiner Arbeit alsdann in das Paket-Repository zur allgemeinen Verwendung hochgeladen.
Änderungswünsche oder Fehlerkorrekturen werden an den Entwickler herangetragen, der sie in eine neue Version des Pakets einarbeitet und das Resultat wieder ins Repository hochlädt.

Um den Zyklus der Änderungen zu Beschleunigen und das Mitentwickeln für Andere einfacher zu machen, sollten also die Delixs-Pakete zukzessiv in das SVN-Repository auf dem Entwicklerserver ausgelagert werden.

Vorarbeiten

Zunächst installieren wir noch etwas Software, um mit dem SVN und der Paketentwicklung arbeiten zu können:

 aptitude install svn-buildpackage libparse-debcontrol-perl 

Es werden nun automatisch die notwendigen Programme zur SVN-Verwaltung installiert. Das Programm 'svn-buildpackage' wird später statt des bisherigen 'debuild' eingesetzt werden.

Wir können schon jetzt ein paar Optionen für dieses Programm setzen, indem wir in unserem Home-Verzeichnis eine entsprechende Konfigurationsdatei anlegen.

 ~/.svn-buildpackage.conf:
 
 svn-builder=debuild -uc -us
 svn-no-links
 svn-dont-clean
 svn-noautodch

Zur Erläuterung: Normalerweise würde svn-buildpackage für den Paketbau das Programm 'dpkg-buildpackage' aufrufen; wir haben uns aber schon an den Komfort des Programms 'debuild' gewöhnt, deshalb definieren wir, dass es als Build-Programm herangezogen werden soll.
Im obigen Beispiel übergeben wir dem 'debuild' noch zwei Optionen, um das Signieren der Pakete zu unterdrücken; spätestens beim Bauen der endgültigen, ins Paket-Repository hochzuladenden Version sollte aber das Signieren wieder eingeschaltet werden.

Zusätzlich müssen wir noch dafür sorgen, dass wir von einem Betreuer des Entwicklerservers als Nutzer des SVN-Repository eingetragen werden.
Der Betreuer wird uns einen Nutzer-Account anlegen und uns die entsprechenden Zugangsdaten zukommen lassen.

Ein Paket ins SVN einpflegen

Es sei vorausgesetzt, dass wir über ein Delixs-Paket verfügen, das bislang an anderer Stelle erzeugt, bearbeitet und in das Paket-Repository des Entwicklerservers hochgeladen wurde.

Wir arbeiten hier beispielhaft mit dem Paket 'delixs-acl-quota' .

Delixs-SVN-Repository auschecken

Im ersten Schritt holen wir uns erst mal den Inhalt des kompletten SVN-Repository, wie es z.Zt. auf dem Entwicklungsserver gespeichert ist. Unser eigenes Paket werden wir dann nahtlos in das Repository einfügen.

 mkdir ~/delixs-svn
 cd ~/delixs-svn
 svn --username XXX --password YYY co http://dev.delixs.de/wsvn/delixs/ ./

Wir erstellen also in unserem Home-Verzeichnis ein SVN-Arbeitsverzeichnis und wechseln dorthin. Der Befehl 'svn' bekommt als Parameter:
--username und --password: das sind die Account-Daten, die wir vom Serverbetreuer erhielten
co: steht für 'checkout'; damit wird im SVN-Jargon das Herunterladen eines SVN-Zweigs bezeichnet
http://dev.delixs.de/wsvn/delixs/ : ist das SVN-Repository auf den Entwicklungsserver
./ : ist das Zielverzeichnis, in das der SVN-Zweig gespeichert wird

Wir erhalten folgende Verzeichnisstruktur in unserem Arbeitsverzeichnis:

 tree -L 1
 .
 ├── delixs
 ├── delixs-archive-keyring
 ├── delixs-installer
 ├── delixs-installer-hjg
 ├── delixs-installer-thorsten
 ├── delixs-installer-udeb
 ├── delixs-netcfg
 ├── delixs-scripts
 ├── installer
 └── svn-tools

In den Unterverzeichnissen befinden sich bereits einige Pakete von anderen Entwicklern.

Uns interessiert aber zunächst nur das Verzeichnis 'svn-tools'.
Darin befindet sich das Programm 'svn-deb-prep.sh', das wir in unser lokales Binär-Verzeichnis kopieren, damit wir es später bequem aufrufen können.

 cp svn-tools/svn-deb-prep.sh /usr/local/bin

Mit diesem Tool werden wir unsere eingenen Pakete in das SVN umziehen.

Paket bereinigen und kopieren

Wenn dieses Paket in das SVN übertragen werden soll, muss es erst noch bereinigt und etwas 'in Form' gebracht werden; außerdem sollte solch ein SVN-Prpjektverzeichnis eine gewisse Struktur aufweisen, damit später einfacher mit verschiedenen Paketversionen gearbeitet werden kann.

Diese Arbeiten erledigt für uns das Tool svn-deb-prep.sh.

Wir wechseln in unser SVN-Arbeitsverzeichnis und rufen dort das Programm auf. Als Parameter übergeben wir den Pfad zum bisherigen Paket-Arbeitsverzeichnis:

 cd ~/delixs-svn
 svn-deb-prep.sh ~/pakete/acl/delixs-acl-quota-0.5

Wir erhalten diese Ausgabe:

 Analyzing Debian package path: '~/pakete/acl/delixs-acl-quota-0.5' ...
   package name is 'delixs-acl-quota', version is '0.5'
 Creating svn working directories ...
 Transfering package data to working dirs ...
 
 Your debian package delixs-acl-quota is ready.
 
 Next steps:
    svn add delixs-acl-quota
    svn commit -m 'Initial upload'

Wir prüfen, ob das Tool richtig gearbeitet hat, und finden in unserem SVN-Verzeichnis neben den vorhin heruntergeladenen Projektverzeichnissen nun auch unser neues Verzeichnis 'delixs-acl-quota'.

 │
 ├── delixs-acl-quota
 │   ├── tags
 │   └── trunk
 │       └── debian
 │           ├── changelog
 │           ├── compat
 │           ├── control
 │           ├── copyright
 │           ├── dirs
 │           ├── docs
 │           ├── postinst
 │           ├── prerm
 │           ├── README
 │           ├── README.Debian
 │           └── rules
 │

Wir erkennen hier die grundsätzliche Struktur eines SVN-Projektverzeichnisses:

Auf der ersten Ebene liegen die Verzeichnisse 'tags' und 'trunk'. Das 'tags'-Verzeichnis können wir zunächst ignorieren (wir kommen später noch darauf zurück) und widmen uns dem 'trunk'.

Das 'trunk'-Verzeichnis ist das Verzeichnis im SVN, das die aktuelle Hauptversion eines Projekts enthält. Alle Arbeiten der Team-Mitglieder, die an diesem Paket arbeiten, werden im 'trunk'-Verzeichnis zusammengeführt.

Man sieht dort die Dateien, die wir für unser Paket 'delixs-acl-quota' angelegt und bearbeitet hatten, allerdings ohne die bisherigen 'debuild'-Ergebnisse (also die *.deb, *.changes usw. Dateien).

Paket in das SVN einfügen

Das Tool hat unser Paket also erfolgreich in das SVN-Arbeitsverzeichnis einkopiert, aber es ist der SVN-Verwaltung noch nicht bekannt gemacht worden.

Den passenden Befehl dazu hat uns das Tool schon angezeigt:

 svn add delixs-acl-quota

Hiermit teilen wir dem SVN mit, dass es zukünftig alle Arbeiten im Projektverzeichnis 'delixs-acl-quota' verwalten soll.

Als Ergebnis erhalten wir:

 svn add delixs-acl-quota
 A         delixs-acl-quota
 A         delixs-acl-quota/trunk
 A         delixs-acl-quota/trunk/debian
 A         delixs-acl-quota/trunk/debian/changelog
 A         delixs-acl-quota/trunk/debian/rules
 A         delixs-acl-quota/trunk/debian/prerm
 A         delixs-acl-quota/trunk/debian/docs
 A         delixs-acl-quota/trunk/debian/README
 A         delixs-acl-quota/trunk/debian/compat
 A         delixs-acl-quota/trunk/debian/control
 A         delixs-acl-quota/trunk/debian/dirs
 A         delixs-acl-quota/trunk/debian/postinst
 A         delixs-acl-quota/trunk/debian/copyright
 A         delixs-acl-quota/trunk/debian/README.Debian
 A         delixs-acl-quota/tags

Der Befehl durchläuft das gesamte Projektverzeichnis und fügt die Dateien und Verzeichnisse seiner SVN-Verwaltungsdatenbank hinzu ('A' = add).

Damit auch andere Entwickler auf dieses Projektverzeichnis zugreifen können, müssen wir unsere lokale Datenbank noch mit dem SVN auf dem Entwicklungsserver synchronisieren.
Auch diesen Befehl hatte uns das Prep-Tool ja empfohlen:

 svn commit -m 'Initial upload'

Hiermit beauftragen wir das SVN, alle von uns durchgeführten Änderungen, in diesem Fall also alle hinzugefügten Dateien und Verzeichnisse, mit dem Server zu synchronisieren.

 svn commit -m 'Initial upload'
 Hinzufügen     delixs-acl-quota
 Hinzufügen     delixs-acl-quota/tags
 Hinzufügen     delixs-acl-quota/trunk
 Hinzufügen     delixs-acl-quota/trunk/debian
 Hinzufügen     delixs-acl-quota/trunk/debian/README
 Hinzufügen     delixs-acl-quota/trunk/debian/README.Debian
 Hinzufügen     delixs-acl-quota/trunk/debian/changelog
 Hinzufügen     delixs-acl-quota/trunk/debian/compat
 Hinzufügen     delixs-acl-quota/trunk/debian/control
 Hinzufügen     delixs-acl-quota/trunk/debian/copyright
 Hinzufügen     delixs-acl-quota/trunk/debian/dirs
 Hinzufügen     delixs-acl-quota/trunk/debian/docs
 Hinzufügen     delixs-acl-quota/trunk/debian/postinst
 Hinzufügen     delixs-acl-quota/trunk/debian/prerm
 Hinzufügen     delixs-acl-quota/trunk/debian/rules
 Übertrage Daten ...........
 Revision 75 übertragen.

Mitarbeit an einem Paket im SVN

Im vorherigen Kapitel haben wir dafür gesorgt, dass ein Delixs-Paket, das wir bislang allein erstellt und bearbeitet hatten, in ein SVN-Repository zur Bearbeitung im Team veröffentlicht haben.

Nun werden wir uns ansehen, wie man als Teammitglied dieses Paket mit SVN-Mitteln bearbeitet und aktualisiert.

Paket auschecken

Falls wir das Paket nicht selbst in das öffentliche Repository eingebracht haben, müssen wir es zunächst in ein lokales Arbeitsverzeichnis auschecken.

 mkdir ~/delixs-svn
 cd ~/delixs-svn
 svn --username XXX --password YYY co http://dev.delixs.de/wsvn/delixs/delixs-acl-quota

Wir erstellen damit in unserem Home-Verzeichnis ein SVN-Arbeitsverzeichnis und wechseln dorthin.

Den Befehl 'svn co' zum Auschecken (Herunterladen) mit den notwendigen Account-Parametern kennen wir ja schon aus dem vorherigen Kapitel.
In diesem Fall checken wir aber nicht das komplette Delixs-SVN-Repository aus, sondern holen lediglich das Paket 'delixs-acl-quota' zur Bearbeitung ab.
Wir beschränken uns auf dieses eine Paket, weil wir ja nur daran mitarbeiten wollen. Wir hätten aber genausogut den kompletten SVN-Zweig auschecken können. Zudem haben wir keinZielverzeichnis angegeben, somit hat das svn-Programm ein Projekt-Unterverzeichnis angelegt.

Als Ergebnis bekommen wir folgende Ausgabe:

 svn --username XXX --password YYY co http://dev.delixs.de/wsvn/delixs/delixs-acl-quota
 A    delixs-acl-quota/trunk
 A    delixs-acl-quota/trunk/debian
 A    delixs-acl-quota/trunk/debian/control
 A    delixs-acl-quota/trunk/debian/dirs
 A    delixs-acl-quota/trunk/debian/compat
 A    delixs-acl-quota/trunk/debian/postinst
 A    delixs-acl-quota/trunk/debian/prerm
 A    delixs-acl-quota/trunk/debian/changelog
 A    delixs-acl-quota/trunk/debian/copyright
 A    delixs-acl-quota/trunk/debian/docs
 A    delixs-acl-quota/trunk/debian/rules
 A    delixs-acl-quota/trunk/debian/README
 A    delixs-acl-quota/trunk/debian/README.Debian
 A    delixs-acl-quota/tags
 Ausgecheckt, Revision 75.

 .
 └── delixs-acl-quota
     ├── tags
     └── trunk
         └── debian
             ├── changelog
             ├── compat
             ├── control
             ├── copyright
             ├── dirs
             ├── docs
             ├── postinst
             ├── prerm
             ├── README
             ├── README.Debian
             └── rules

Wir wechseln in das Unterverzeichnis 'delixs-acl-quota/trunk', um unsere Arbeit dort (fast) wie bei jedem anderen Debian-Paket fortzusetzen.

Der Zyklus

Die folgenden Schritte beschreiben die wesentlichen Tätigkeiten, die während der Arbeit an einem Team-Projekt anfallen.
Diese Arbeiten werden typischerweise so oft wiederholt, bis das Projekt die gewünschten Funktionalitäten aufweist. Wir beschreiben also einen häufig durchlaufenen Arbeitszyklus.

Arbeitskopie aktualisieren

Sofern wir das Paket nich gerade erst ausgecheckt haben, sollten wir zunächst nachprüfen, ob ein anderes Teammitglied Änderungen vorgenommen hat.

Hierfür gibt es den SVN-Befehl 'update'

 svn update
 Revision 75.

Da kein anderes Teammitglied bislang Änderungen an diesem Projekt vorgenommen hat, bekommen wir als Ergebnis der Update-Prozedur nun lediglich die aktuelle Revisions-Nummer angezeigt.

Paket bearbeiten

Nun können wir hingehen und die Projektdateien bearbeiten.

Typischerweise würden wir nun z.B. eine neue Fuktion in das 'postinst'-Skript einbringen, daraus ein Paket bauen, die Installation des Pakets testen, anschließend eventuelle Fehler korrigieren etc.

An dieser Vorgehensweise hat sich auch nichts geändert; der einzige Unterschied zu unserer gewohnten Arbeit besteht darin, dass wir zum Paket-Bauen nicht mehr das Programm 'debuild', sondern statt dessen den Befehl 'svn-buildpackage' verwenden.

Warum wir das tun, schauen wir uns einfach mal an einem Beispiel an.

 cd ~/delixs-svn/delixs-acl-quota/trunk
 
 svn-buildpackage --svn-ignore
 
 Imported config directives:
         --svn-builder=debuild -us -uc
         --svn-no-links
         --svn-dont-clean
         --svn-noautodch
 Complete layout information:
         tagsDir=~/delixs-svn/delixs-acl-quota/tags
         tagsUrl=http://dev.delixs.de/wsvn/delixs/delixs-acl-quota/tags
         trunkDir=~/delixs-svn/delixs-acl-quota/trunk
         trunkUrl=http://dev.delixs.de/wsvn/delixs/delixs-acl-quota/trunk

Wir wechseln also zunächst in das 'trunk'-Verzeichnis unseres Projekts, denn nur aus diesem Verzeichnis heraus kann der Build-Vorgang gestartet werden (in dieser Hinsicht war das alte 'debuild' etwas flexibler).
Dann starten wir das Programm 'svn-buildpackage' mit der Option 'svn-ignore'. Weshalb wir diese Option verwenden, klären wir gleich.

Das Programm zeigt uns erst an, welche Optionen es aus unserer Konfigurationsdatei (s. Kapitel 2) übernommen hat, und listet dann die Kenndaten unseres lokalen und des öffentlichen SVN-Repository auf.

Dann laufen die Build-Ausgaben ab ...

 Orig tarball not found (expected ../tarballs/delixs-acl-quota_0.5.orig.tar.gz)
 svn --force export ~/delixs-svn/delixs-acl-quota/trunk ~/delixs-svn/delixs-acl-quota/build-area/delixs-acl-quota-0.5
 Export abgeschlossen.
 chmod -R u+r+w+X,g+r-w+X,o+r-w+X -- ~/delixs-svn/delixs-acl-quota/build-area/delixs-acl-quota-0.5
 /bin/sh -c debuild -us -uc
 
   ... [ hier stehen die gewohnten 'debuild'-Meldungen } ...
 
 Finished running lintian.
 build command was successful; binaries are in ~/delixs-svn/delixs-acl-quota/build-area/. The changes file is:
  ~/delixs-svn/delixs-acl-quota/build-area/delixs-acl-quota_0.5_amd64.changes
 Binary package:
  ~/delixs-svn/delixs-acl-quota/build-area/delixs-acl-quota_0.5_all.deb
 rm -rf ~/delixs-svn/delixs-acl-quota/build-area/delixs-acl-quota-0.5

... und enden mit der Erfolgsmeldung build command was successful.

Schauen wir uns kurz unsere Verzeichnisstruktur an:

 .
 └── delixs-acl-quota
     ├── build-area
     │   ├── delixs-acl-quota_0.5_all.deb
     │   ├── delixs-acl-quota_0.5_amd64.build
     │   ├── delixs-acl-quota_0.5_amd64.changes
     │   ├── delixs-acl-quota_0.5.dsc
     │   └── delixs-acl-quota_0.5.tar.gz
     ├── tags
     ├── tarballs
     └── trunk
         └── debian
             ├── changelog
             ├── compat
             ├── control
             ├── copyright
             ├── dirs
             ├── docs
             ├── postinst
             ├── prerm
             ├── README
             ├── README.Debian
             └── rules

Wir stellen fest, dass zwei neue Verzeichnisse hinzugekommen sind, nämlich 'tarballs' und 'build-area'.
Im Verzeichnis 'build-area' stehen offensichtlich die Ergebnisse unseres Build-Vorgangs, die wir ja normalerweise in dem 'delixs-acl-quota'-Verzeichnis erwartet hätten. Und auch ein Blick in das 'debian'-Verzeichnis zeigt uns, dass die sonst üblichen Build-Dateien und das Build-Unterverzeichnis fehlen; das 'debian'-Verzeichnis ist so unberührt und sauber, als ob wir gar keinen Build ausgeführt hätten.

Und das ist auch der eigentliche Grund, warum wir statt des 'debuild' nun 'svn-buildpackage' verwenden:
das in die SVN-Datenbank eingepflegte Verzeichnis wird nicht durch unnütze Dateien überhäuft, wir sehen hier nur die Dateien, die zum Kern des Projekts gehören, die wir selbst bearbeiten und die wir mit den anderen Teammitgliedern teilen wollen.

Noch kurz zur Option 'svn-ignore':
normalerweise erwartet svn-buildpackage, dass wir unsere Änderungen vorher mit dem SVN-Repository abgleichen. Wenn man allerdings sehr häufig den Edit-/Build-/Testzyklus durchläuft und seine Änderungen jedesmal abgleicht, würden die Revisions-Nummern, unter denen das SVN jede Änderung protokolliert, sehr schnell in astronimische Höhen schnellen.

Deshalb ist es besser, den Abgleich mit dem SVN-Repository nur dann durchzuführen, wenn sinnvolle Arbeitsschritte erfolgreich getestet wurden; bis dahin sagen wir dem svn-buildpackage durch unsere 'svn-ignore'-Option, dass es Änderungen an unseren Projektdateien erst mal ignorieren soll.

Wenn wir unsere Arbeit dann mal mit dem Repository abgleichen möchten, setzen wir den Befehl 'svn commit' ab:

 svn commit -m 'Funktion get_data eingefuegt'
 Sende          delixs-acl-quota/trunk/debian/postinst
 Übertrage Daten .
 Revision 76 übertragen.

Wir geben dem Befehl durch den Parameter -m noch gleich eine kleine Erläuterung mit, was an dieser Revision geändert wurde und lassen unser lokales SVN mit dem öffentlichen SVN abgleichen.

Jetzt haben unser lokales und das öffentliche SVN-Repository wieder den selben Stand und ein 'svn-buildpackage' würde nun auch ohne den Parameter einwandfrei durchlaufen.

Änderungen des Teams einarbeiten

Wir nehmen noch eine wichtige Änderung an dem 'postinst'-Skript vor und möchten es mit dem öffentlichen SVN synchronisieren:

 svn commit -m 'exit-status geaendert'
 Sende          debian/postinst
 svn: Übertragen schlug fehl (Details folgen):
 svn: Datei »/delixs-acl-quota/trunk/debian/postinst« ist veraltet

Da wir jetzt in einem Team gemeinsam arbeiten, ist es nicht unüblich, dass auch Andere Veränderungen an den Projektdateien vornehmen.
Das ist hier wohl zwischenzeitlich passiert; der svn-Befehl konnte unsere Änderungen nicht hochladen, da unsere Version der Datei veraltet ist. Wir müssen zunächst die Änderungen der anderen Teammitglieder in unseren Datenbestand aufnehmen, bevor wir uns wieder mit dem öffentlichen Repository synchronisieren können.

Schauen wir uns zunächst den aktuellen Status an:

 svn status -u
 M       *        76   postinst
         *        49   README.Debian
 Status bezogen auf Revision:      77

Der Parameter -u bewirkt, dass der Status-Befehl auch den aktuellen Stand im öffentlichen Repository berücksichtigt.

Es werden uns zwei geänderte Dateien angezeigt;
das 'M' in der ersten Spalte zeigt an, dass wir die Datei modifiziert haben.
Das '*'-Symbol weist darauf hin, dass die öffentlich Version geändert und wir diese in unsere eigene Version integrieren müssen.

SVN synchronisieren

Dieses Integrieren geht glücklicherweise i.d.R. automatisch vonstatten, indem wir ein beherztes 'svn update' absetzen.

 svn update
 G    postinst
 D    README.Debian
 Aktualisiert zu Revision 77.

Das Update, also das Synchronisieren unserer und der öffentlichen Dateien, war erfolgreich.

Die Datei 'postinst' hat den Status 'G' (merGed); das bedeutet, dass unsere Änderungen und die Änderungen eines Teammitglieds ohne Probleme zusammengeführt werden konnten.
Die Datei 'README.debian' ist von einem anderen Mitarbeiter gelöscht (Deleted) worden.

Eine vollständige Erläuterung aller Status-Codes erhält man mit svn help status.

Konflikte lösen

Leider ist das SVN nicht immer in der Lage, alle Änderungen der Teammitglieder an der selben Datei völlig problemlos zusammenzuführen.

 svn update
 Konflikt in »postinst« entdeckt.
 Auswahl: (p) zurückstellen, (df) voller Diff, (e) editieren,
          (mc) eigene konfliktbehaftete Datei, (tc) fremde konfliktbehaftete Datei,
          (s) alle Optionen anzeigen:

In unserem Beispiel haben wir und ein anderes Teammitglied die selbe Zeile der Datei 'postinst' geändert. In einem solchen Fall meldet das Update-Programm einen Konflikt, es muss der Mensch entscheiden, was passieren soll.

Sobald das Update-Programm den Konflikt erkennt, gibt es uns verschiedene Möglichkeiten zur Reaktion.
Für welchen Weg wir uns auch immer entscheiden, wir müssen den Konflikt eindeutig lösen, bevor das 'svn update' erfolgreich die Reposoitories synchronisieren kann.

Auf die verschiedenen Varianten zur Konfliktlösung gehe ich an dieser Stelle nicht nähger ein; der Interessierte mag hierzu das SVN-Buch konsultieren (s. Weblinks).

Üblicherweise werden wir einen Konflikt angehen, indem wir die betreffende Datei editieren; wir geben in die Auswahl-Abfrage also 'e' ein.

 <<<<<<< .mine
   print STDERR "postinst called without any argument\n";
   exit(2);.
 =======
   print STDERR "postinst ohne Parameter aufgerufen\n";
   exit(1);.
 >>>>>>> .r77

Es startet unser Standard-Editor mit der Konflikt-Datei, und wenn wir nach dem Begriff '<<<<<<<' suchen, wird uns eine/die Konfliktstelle angezeigt.

Zwischen den vielen Kleiner- und Größer-Zeichen befinden sich, getrennt durch mehrere '====' die in Konflikt stehenden Textpassagen, wobei unsere Änderungen zuerst angezeigt werden.

Wir müssen jetzt, am besten in Absprache mit dem anderen Teammitglied, für die 'richtige' Version sorgen, indem wir die Konfliktmarker entfernen und den Quelltext entsprechend der Absprache anpassen.

Nachdem wir die Datei in der neuen Version gespeichert haben, wird uns wieder das Auswahlmenu angezeigt.
Wir können den Konflikt als aufgelöst (Resolved) anzeigen.

 Auswahl: (p) zurückstellen, (df) voller Diff, (e) editieren, (r) aufgelöst,
          (mc) eigene konfliktbehaftete Datei, (tc) fremde konfliktbehaftete Datei,
          (s) alle Optionen anzeigen: r
 G    postinst
 Aktualisiert zu Revision 78.

Das Updateprogramm hat keine weiteren Probleme und meldet uns ein 'zusammengeführt' (merGed).
Wir können jetzt also nochmal ein 'svn commit' absetzen und werden erfolgreich sein.

Dateien hinzufügen oder löschen

Natürlich wird es gelegentlich nötig sein, unserem Projekt neue Dateien oder Verzeichnisse hinzuzufügen oder auch bestehende Dateien zu löschen.

Hier genügt es nicht, die Dateien in unserem Arbeitsbereich mit den Mitteln des Betriebssystems anzulegen. Das SVN kennt diese Dateien nicht und wird sie auch nicht in das Repository hochladen.

Dem SVN neue Dateien/Verzeichnisse bekannt machen:

  svn add dateixy

Ab jetzt werden diese Dateien vom SVN beobachtet und im Repository geführt.

Das Löschen geht ebenso einfach:

  svn del datei123

Paket abschließen

Wir haben unsere ToDo-Liste für die notwendigen Arbeiten an unserem Paket abgearbeitet, ebenso wie die anderen Teammitglieder ihren Beitrag geleistet haben.

Das letzte 'svn-buildpackage' war erfolgreich, das Paket ist getestet; wir sind also bereit, das Paket in seiner jetzigen Version in das Paket-Repository hochzuladen und der Allgemeinheit zur Verfügung zu stellen.

Der Maintainer des Pakets hat nun die Aufgabe, den aktuellen Stand im SVN-Revisionssystem einzufrieren, das Paket zu signieren und auf den Entwicklungsserver hochzuladen.
Hierzu wird der Parameter 'svn-tag' verwendet:

 svn-buildpackage  --svn-tag
 Imported config directives:
         --svn-builder=debuild -us -uc
         --svn-no-links
         --svn-dont-clean
         --svn-noautodch
 ...
 Finished running lintian.
 build command was successful; binaries are in ~/delixs-svn/delixs-acl-quota/build-area/. The changes file is:
  ~/delixs-svn/delixs-acl-quota/build-area/delixs-acl-quota_0.5_amd64.changes
 Binary package:
  ~/delixs-svn/delixs-acl-quota/build-area/delixs-acl-quota_0.5_all.deb
 Repository lookup, probing 'http://dev.delixs.de/wsvn/delixs/delixs-acl-quota/tags/0.5' ...
 Tagging delixs-acl-quota (0.5)
 svn -m [svn-buildpackage] Tagging delixs-acl-quota 0.5 cp . http://dev.delixs.de/wsvn/delixs/delixs-acl-quota/tags/0.5
 
 Revision 79 übertragen.
 
 I: Done! No pending changelog entry was created since it was not requested.
 rm -rf ~/delixs-svn/delixs-acl-quota/build-area/delixs-acl-quota-0.5

Ein 'svn status -u' zeigt uns, was passiert ist:

 svn status -u
         *            tags/0.5/debian/README
         *            tags/0.5/debian/control
         *            tags/0.5/debian/dirs
         *            tags/0.5/debian/compat
         *            tags/0.5/debian/postinst
         *            tags/0.5/debian/prerm
         *            tags/0.5/debian/changelog
         *            tags/0.5/debian/copyright
         *            tags/0.5/debian/docs
         *            tags/0.5/debian/rules
         *            tags/0.5/debian
         *            tags/0.5
         *        1   tags
 ?                    tarballs
 ?                    build-area
 Status bezogen auf Revision:      79

Der 'svn-tag'-Parameter hat im öffentlichen SVN-Repository in dem bislang unbenutzten 'tags'-Unterverzeichnis eine Kopie (Snapshot) unseres aktuellen Standes unter dem Namen '0.5', also der aktuellen Paket-Versionsnummer, erzeugt.

Alle Arbeiten, die ab jetzt im 'trunk'-Verzeichnis durchgeführt werden, sollten unter der nächsten Versionsnummer erfolgen, deshalb werden wir als erstes die Version inkrementieren und diesen neuen Stand unseren Mitstreitern übermitteln:

 dch -im
 
 svn commit -m 'Anfang version 0.6'
 Sende          trunk/debian/changelog
 Übertrage Daten .
 Revision 80 übertragen.

Hinweis: Damit das Paket für das Download-Repository auch ordnungsgemäß signiert wird, sollte der Maintainer vor dem abschließenden 'svn-buildpackage ---svn-tag' in seiner svn-Konfigurationsdatei ~/.svn-buildpackage.conf den Eintrag 'svn-builder=debuild -uc -us' kurzzeitig auskommentieren.

Weblinks

Buch 'Versionskontrolle mit Subversion':

• http://svnbook.red-bean.com/nightly/de/index.html

---

zurück | Hauptseite

Hans-Jürgen Grimminger, 2011