Entwicklerhandbuch/Delixs-SVN
Diese Seite ist momentan eine Baustelle im Zustand: 2
-
0
-
1
-
2
-
3
-
4
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':
Hans-Jürgen Grimminger, 2011