[Allegro] Fragen zur SVN Struktur für acon

[Thomas Berger]

Lieber Herr Eversberg,

>   https://svn.allegro-c.de/svn/acon
> 
> denn nun am besten in eine Struktur mit einem "tag" für jede definierte Version
> überführen?
> 
> Also konkret:
> 
> 1. Soll es Verzeichnisse  "trunk"  und  "tags"  geben, oder
>    lieber - weil das ja reine Konventionen sind - mehr intuitiv benannt
>    als  "work"  und  "releases"?
>    Von "branches" wollen wir erst mal absehen.

Eine einfuehrende Diskussion mit Illustrationen typischer Konfigurationen
finden Sie etwa unter

http://svnbook.red-bean.com/nightly/de/svn.reposadmin.planning.html

Grundlegend waere m.E. erst noch einmal zu ueberlegen, ob Sie wirklich
separate Repositorien fuer "acon", "ac15", "aindex" etc. haben wollen,
oder ob das nicht verschiedene *Projekte* in /einem/ Repository sein
sollen. Bzw. sogar nur verschiedene Unterprojekte eines Gesamtprojekts
"allegro".

Auf dem "Trunk" spielt sich die (Haupt-)Entwicklung ab, bei CVS hiess
das HEAD (bei git auch). Hiervon werden die Releases "gemacht", indem
man eine Momentaufnahme mit einem (aussagekraeftigen) Tag versieht.
Solche Tags sind Verweise auf einen bestimmten Zustand und werden im
"tags"-Verzeichnis abgelegt (sehen dort dann aus wie Kopien und
funktionieren auch so). Bei x (~12) Releases pro Jahr wird das mittelfristig
unuebersichtlich, ich empfehle daher eine zweistufige Struktur:

tags/
...
tags/v32/
...
tags/v32/03

Tags sind statisch und erlauben (vom Paradigma her, technisch ist das
nicht verboten) absolut keine Fortschreibung durch "minimale Korrekturen":
Wenn v32.03 als Tag vergeben ist, dann gilt es als absolutes No-no,
diese Version auszuchecken, zu "reparieren" und die geaenderte Version
wieder einzuchecken. Ist die zu veraendernde Version real noch nicht
ausgeliefert, kann man das Tag natuerlich loeschen und fuer die
verbesserte Version neu vergeben, ansonsten ist es besser, ein modifiziertes
Tag v32.03a zu vergeben...

v32.03 ist strenggenommen die Versionsnummer von inst-all.exe, welches
diverse Executables enthaelt, die jeweils in Einzelprojekten enthalten
sind. Weil aber der Sinn des Taggens vermutlich darin bestehen duerfte
festzuhalten, aufgrund welcher Versionen etwas releast wurde, wird man
dennoch Tagnamen waehlen, die sich in Bezug auf die Versionsnummern
setzen. Das waere ein Argument fuer das Layout in Form von Unterprojekten,
dann kann vom Gesamtprojekt ein Schnappschuss in Form eines Tags
angelegt werden.

Es gibt die Moeglichkeit, ein virtuelles Gesamtprojekt "inst-all"
anzulegen, das die relevanten Einzelprojekte per svn:external
/einbindet/. Es wird allerdings bei svn:externals davon abgeraten, den
Trunk der Einzelprojekte einzubinden, sondern getaggte ("stabile"!?)
Versionen davon. Release von inst-all wuerde also voraussetzen,
zunaechst die Einzelprojekte zu taggen, dann die Tags in den svn:exteral-
Einbindugnen im Geamtprojekt entsprechend anzupassen, das per svn
update zu aktualisieren und anschliessend (anlaesslich des Release-
Baus) selbst zu taggen. Das ist etwas aufwendig, stellt aber sicher,
dass die Gesamtpakete nur mindestens halbwegs stabile Versionen der
Einzelmodule enthalten (vorausgesetzt, das Gesamtpaket wird anhand des
virtuellen Projekts gebaut): Wenn ein Geamtpaket schnell veroeffentlicht
werden muss, weil eine dringende Korrektur in einem Modul erfolgt ist,
ist das dann nicht dadurch entwertet, dass es die aktuellste, aber
leider etwas instabile Version eines anderen Moduls enthaelt...

Es gibt ein 3rd-Party-Tool, das auch per svn:external angebundene Baeume taggen
kann:
https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svncopy/
>>>
This Perl script copies one Subversion location or set of locations to another,
in the same way as svn copy.  Using the script allows more advanced operations,
in particular allowing svn:externals to be dealt with properly for branching
or tagging.
<<<

Vermutlich waere es gar nicht verkehrt, das, was derzeit auf mehrere
Repositories aufgeteilt ist, zumindest als isolierte Projekte zu
erhalten (insbesondere avanti, ztarget und weitere haben ja auch
traditionell ganz andere Release-Zyklen als das Gesamtpaket), und irgendwann
duerften die Libraries ja auch in dynamische umgewandelt werden (ein
400kB grosses acon.exe aufzustarten /ist/ ein Performance-Killer, weil
nicht nur die CPU-Zeit zum Initialisieren verbraten wird, sondern auch
viele Bloecke von der Platte gelesen werden muessen, um ueberhaupt an
den Binaercode zu kommen), so dass die Bibliotheksprojekte nicht mehr
integraler Bestandteil eines jeden Buildprozesses fuer die Anwendungs-
programme sein muessen.


"branches" sind nicht unbedingt fuer Clones eines Projekts gedacht, sondern
dafuer, lang- und kurzfristigen Entwicklungsarbeiten ihren Raum zu geben:
Schnelle Reparaturen finden direkt im Trunk statt (dort sollte ja stets eine
im wesentlichen funktionierende Version zu finden sein), groessere Umbauten
und Funktionalitaetsverbesserungen in Branches: was dort geschieht, gefaehrdet
nicht die Stabilitaet des Trunks. Ist diese Teilentwicklung fertig, kann
sie in den Trunk "integriert" werden, der Branch wird dann geloescht. [Eine
andere Nutzung von Branches kommt dann zur Anwendung, wenn man auch
"fruehere" Versionen supported: "Major Revisions" bringen ggfls. Anpassungs-
aufwand beim Endnutzer (durch Inkompatibilitaeten, Aenderungen in
Datenstrukturen) oder sind zumindest nicht reversibel, daher gibt es dann
parallel zu Minor Releases der aktuellen Version eine gewisse Zeit lang
ebenfalls neue Releases der vorigen Version: Als die seinerzeit ausgehend vom
Trunk released worden ist, wurde dafuer (v31-stable) ein neuer Branch angelegt
und die Entwicklung im Trunk schritt munter voran Richtung v32. Wichtige
Aenderungen im Trunk werden dann auf den v31-stable-branch uebertragen,
der sich damit in Richtung eines Releases v31.13 entwickelt.]


> 2. Wie würde man das konkret ausführen, mit welchen svn-Befehlen also?
>    (Um nicht unnütz herumzuexperimentieren und Verzeichnisse zu
>    schaffen, die man erst wieder mühsam beseitigen muß...)

[Wenn es innerhalb eines Repositories sich abspielt:]

Mit einem graphischen SVN-Client, etwa Tortoise-SVN sollte das ganz
intuitiv gehen: In der Baum-Ansicht ein Unterverzeichnis erstellen, anderes
dort hineinverschieben. Laestig natuerlich, dass viele Einzeldateien direkt
unterhalb der Wurzel liegen, die sollten sich aber alle gemeinsam mit der Maus
"greifen" lassen.

Sie haben dabei die Wahl, die Operationen direkt am Repository
vorzunehmen (jede Operation wird dann ein einzelnes commit), oder
lokal an einer ausgecheckten Kopie der gesamten Angelegenheit mit
einem zusammenfassenden Commit am Ende.

An der Kommandozeile geht es natuerlich auch (vorausgesetzt Sie haben
"svn" als Kommando).

viele Gruesse
Thomas Berger