CVS-Konzept

Mit release 0.3 wurde die cvs Struktur von udrec_suite von Grund auf verändert. Dieses Dokument beschreibt die neue Struktur und das der Struktur zugrunde liegende Konzept.

• Ziele
• Struktur

Ziele

Die cvs Struktur dieses Projekts verfolgt drei Ziele aus Sicht des Entwicklers:

• Freigegebene Releases müssen nachvollzogen und Bugfixes daran vorgenommen werden können
• Gleichzeitig muss er davon unabhängig den Code erweitern und verändern zu können, ohne die Fehlerbereinigung eines aktuellen Releases zu beeinträchtigen
• Bugfixes eine Release müssen aber dennoch auch der aktuellen Entwicklung zugute kommen

Ein weiteres Ziel der hier vorgestellten cvs Struktur ist die einfache Bereitstellung von aktuellen Releases mit Bugfixes für Personenkreise die nicht direkt mit der Entwicklung zu tun haben und deshalb auch keinen tieferen Einblick in die cvs Struktur haben. Ein Tester des Codes soll sich mittels eines einfachen Befehls wie z.B.

        cvs checkout udrec_suite

diesen Code besorgen können.

Struktur

Um dies zu erreichen wurde folgender Weg beschritten (illustriert durch das Bild):(!nl)

Wurde ein neues Release fertig gestellt, wird es im HEAD abgelegt und mit einem Tag versehen. Die Release 0.3 von udrec_suite ist z.B. über den Tag rel-0-3-0-0 abrufbar. Gleichzeitig mit Erstellung dieses Tags wird ein branch erzeugt, der der Weiterentwicklung mit dem Ziel einer neuen Release 0.4 dient. Der Branch ist über den Tag dev-0-4-0-0 abrufbar, also

        cvs checkout -r dev-0-4-0-0 udrec_suite

Bugfixes werden von den Entwicklern im HEAD ausgeführt, d.h. ausgecheckt wird wie weiter oben beschrieben ohne Angabe von irgendwelchen Tags. Entscheiden sich die Entwickler zur Freigabe einer Bugfix-release 0.31, dann wird diese im HEAD mit einem Tag versehen, im Beispiel ist das rel-0-3-1-0.

Wenn Bugfixes aus dem HEAD in die Entwicklung der Release 0.4 einfliessen sollen, müssen Sie vom HEAD in den branch gemergt werden. Dies erfolgt zu irgendwelchen Zeitpunkten die in keinem Zusammenhang mit der Freigabe einer Bugfix-Release stehen. Das bedeutet, die Entwickler können sich beispielweise bis zur Freigabe der Release 0.31 zwei mal entschieden haben, den merge durchzuführen. Jedes mal wird der Stand im HEAD getaggt, d.h. beim ersten merge ist dies der Tag rel-0-3-0-1, beim zweiten merge der Tag rel-0-3-0-2. Erfolgt der merge nach Freigabe der Bugfix-release 0.31, wird der Tag entsprechend rel-0-3-1-1 sein.

Soll ein neues Release 0.4 freigegeben werden, werden die Features etc. aus dev-0-4-0-0 in den HEAD gemergt. Der HEAD bekommt dann einen neuen Tag rel-0-4-0-0 und es wird ein neuer Entwickler Branch dev-0-5-0-0 erzeugt.

[Seitenanfang]