[Allegro] SVN umgeschaltet: svn.allegro-c.de/svn/

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

> Weil das SVN ganz neu aufgesetzt wurde und mit dem jetzt erreichten
> Stand von avanti starten soll, sahen wir auch wenig Sinn darin,
> sofort den voluminösen Inhalt des alten SVN hier zu reproduzieren, also
> den gesamten Ballast mit reinzupacken, der zu diesem Zustand geführt
> hat aber nun obsolet ist. Wer, außer Ihnen, würde sich damit
> herumzuschlagen die Zeit finden?

Niemand, auch ich nicht. Ich habe kein Problem damit, dass etwas,
das vorher nicht verfuegbar war, nun erstmalig verfuegbar ist
und nicht gleich seine ganze Versionsgeschichte mitschleppt. Mit
meinen Einwaenden hatte ich eher das Verhaeltnis von heutiger
Version zu zukuenftigen im Sinn.

Und auch jene, die auch langfristig nur lesend mit dem Repository
arbeiten.


> Wir würden es sehr begrüßen, wenn Sie jetzt mal den Inhalt von ./avanti
> nähmen und ein Repositorium daraus zimmerten, das exakt Ihren
> Vorstellungen entspricht und das wir dann replizieren könnten, was
> wir gerne sofort täten. OpenSource heißt ja eben nicht, daß eine
> zentrale Stelle alles macht und alle andern nur mosern. Sondern genau
> dieses "Kooperationsmodell" gilt es doch zu überwinden. Dazu können Sie
> gerne auch, zumindest erst mal zeitweise, Schreibrecht kriegen und
> die Einrichtung gleich am zentralen Ort vornehmen.

Danke fuer das Angebot, aber das hilft gerade an dieser Stelle wenig:
Es geht ja darum (vergleichbar dem Neubau eines Lesesaals), die
Regale fuer eine systematische Aufstellung einzurichten ("avanti"
waere da eine Sachgruppe, die mit anderen in Nachbarschaftsbeziehungen
steht) und dabei auch die Anforderungen des Betriebs (Raum fuer
Leitern und Buecherwagen, Regale muessen von den Benutzerarbeitsplaetzen
aus zugaenglich sein) einzubeziehen.

Vor dem Hintergrund, dass eine Installation eines Subversion Servers
eine beliebige Anzahl von Repositories verwalten kann, liefert das
Subversion-Buch hier 6 Zeilen Text mit drei vertiefenden Links:
http://svnbook.red-bean.com/en/1.5/svn.tour.importing.html#svn.tour.importing.layout

Speziell
http://svnbook.red-bean.com/en/1.5/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout
hat dann einige Ueberlegung zur Planung. Und in
http://svnbook.red-bean.com/en/1.5/svn.branchmerge.using.html
wird das etwas motiviert.

[Sehr ausfuehrlich und anschaulich die Beschreibung der Konzepte
Branch und Tag im Mercurial-Book
http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html ]


Ihr Projekt
http://svn.allegro-c.de/svn/semapp/
hat bereits (bis auf das mir nicht zugaengliche "ubbs") die ueblicherweise
vorgeschlagene Struktur.

Das "/svn/" in Ihren URLs duerfte der Name des konkreten Repositories sein,
parallel dazu koennten andere liegen, z.B. wenn andere Communities (etwa
"UB intern") bedient werden sollen oder - vgl. meine Anregung gestern -
ein "Quell"-Archiv schlank (und konsistent) gehalten werden soll und
daher Binaries (wenn ueberhaupt) in einem anderen Repository archiviert
werden. Kandidaten fuer das Auslagern in ein separates Repository sind
m.E. /svn/download/installers und /svn/download/prog (die nicht-Binaries
muessten aber strenggenommen auch in der alten Struktur verbleiben, die
resultierende Dopplung ist unschoen und potentiell fehlertraechtig,
aber wohl nicht vermeidbar: avanti.con z.B. liegt ja auch bereits in
unabhaengigen Versionen in download/prog und avanti/ )

Neben "semapp" haben Sie verschiedene Projekte, derzeit a30, acon und avanti
(die moeglicherweise gewisse Definitionsdateien oder auch Libraries mit anderen
Projekten teilen werden). Formales Kriterium fuer "Projekt" ist, dass
jeweils eine Anwendung generiert wird, technisches Kriterium ist, dass man
anhand der in einem Projekt enthaltenen Dateien tatsaechlich etwas
compilieren kann und das nicht deswegen scheitert, weil irgendwelche Dateien
aus einer anderen Ecke des Repositories fehlen.
Avanti koennte auch als Hilfsprogramm fuer acon aufgefasst werden, Ihre Praxis
der seit Jahren recht unabhaengigen Bereitstellung (und die Tatsache, dass
es Makefiles etc. gibt, die eine separate Generierung ermoeglichen) zeigt
aber, dass avanti ein von acon unabhaengiges Projekt ist.

acon, avanti (a99, index, qrix, import, ...) als Projekte, die ein Executable
fuer konkrete Plattformen produzieren sind natuerlich von einer anderen
Qualitaet als eine Webanwendung wie a30 oder phpac oder halbwegs gut
abgrenzbare Flex-Bibliotheken wie alf oder order. Oder irgendwann
die Klassenbibliothek als Projekt, die zwar "nur" eine Library erzeugt,
sich aber klarerweise nicht einem einzigen der anderen Projekte zuordnen
laesst. Weil es administratorenfreundlich ist, acon und avanti zusammen
auszuliefern nebst einer Demodatenbank, beide aber getrennte Projekte
sind, ist es aber auch denkbar, dass der (bzw. die plattformabhaengigen)
Routinen, die so eine Distribution aufbauen, wiederum ein eigenes
Projekt darstellen ("normal" ist natuerlich das "make distrib").

Eventuell wollen Sie also zwischen "/svn" als dem Namen des Repositories und
"acon" als Projektnamen noch eine Verzeichnisebene einziehen, die beim
Gruppieren der verschiedenen Projekte hilft. apps (bzw. guiapps, conapps,
webapps, flexapps, ...), libs, packages, utils, web, ... waeren knackige Namen,
es lohnt aber nicht unbedingt, sich hier viel Struktur auszudenken mit der
man hinterher, wenn konkrete Projekte einzusortieren sind, dann doch nicht
so recht zufrieden ist: Nachtraegliches Verschieben geht immer.

Innerhalb der Projekte sollte allerdings von vorneherein eine gleichmaessige
Struktur realisiert werden. Das Projekt ist die logische Einheit, auf der
ein Entwickler i.A. operiert, die technische Einheit (also das, was er sich
auf seine lokale Platte checkoutet) ist eine bestimmte Version davon (und
deren History, die natuerlich stets gemeinsame Anteile mit der History anderer
Versionen hat).

Unterhalb von avanti und allen anderen Projekten sollte daher moeglichst
ganz schematisch die uebliche (warum nicht) Struktur eingerichtet werden:

avanti/trunk/
avanti/branches/
avanti/tags/

Unterhalb von "trunk" liegt dann der "Ist-Zustand" des Projekts (also das,
was momentan direkt unterhalb von "avanti" sitzt). Die Bedeutung der
trunk-Versíon ist, dass hier etwas liegt, das normalerweise funktionsfaehig
ist (sich fehlerfrei compilieren laesst, ein zunaechst lauffaehiges
Programm erzeugt, d.h. neue Bugs oder Regressionen zeigen sich nicht
unmittelbar). Festschreibungsphasen u. dgl. sind informell geregelt
(eine zeitlang werden nur bekanntgewordene Probleme bearbeitet, keine
neuen Features eingebaut) daraus entsteht dann etwas besonders stabiles
(aka Release), diese Versionen werden dann durch "kopieren" (eine extrem
schnelle und leichtgewichtige Operation) in den "tags"-Baum (etwa
tags/V31.2 ) fuer leichtere Zugaenglichkeit festgehalten. An Versionen
im tags-Baum werden traditionell keine spaeteren Aenderungen mehr
vorgenommen.

Anders sieht es mit den "branches" aus, fuer die es diverse Nutzungs-
szenarien gibt:
- - Waehrend der Festschreibungsphase laeuft parallel bereits die
  Entwicklung fuer die naechste oder uebernaechste Version
- - Zu einer vergangenen Version wird ein "Maintenance-Tree" gefuehrt,
  in den nur die wichtigsten Bugfixes aus der aktuellen Entwicklung
  einfliessen
- - Entwickler wollen sich gegenseitig experimentelle Versionen
  zugaenglich machen (bzw. arbeiten gemeinsam daran)
- - Hilfsentwickler dienen dem Verantwortlichen fuer den "trunk" verbesserte
  Versionen an
...

D.h. bereits beim Ein-Entwickler-Modell (wie ich es ja z.B. auch fuer
meine eigenen Repositories praktizieren) gibt es zwischen "Projekt"
und "aktuellen Inhalten" verzeichnistechnisch eine Zwischenschicht,
die eine Versionsverwaltung dann m.E. auch erst von einem nackten
DAV-Laufwerk (Festplatte mit Gedaechtnis) unterscheidet.

Der Baum "download" bleibt speziell: Hier warten "aktuelle Versionen"
von (meist, mehr oder weniger) Klartext-Dateien darauf, irgendwann
einmal eigenen Projekten zugeordnet zu werden. Eine Struktur mit
"trunk" und "tags" (und branches kann nie schaden) gaebe aber auch
hier die Moeglichkeit, die mit einer bestimmten Version ausgelieferten
Dateien einfach zugreifbar zu halten (bislang muss man ein geeignet
datiertes inst-all.exe finden, installieren und schauen, was
herauspurzelt).

Ich hoffe, das war jetzt nicht zu geschwaetzig, aber es geht bei
diesen Layout-Geschichten ganz stark darum, dass alle Nutzer eines
Repositories (vor allem die mit Schreibrecht) sich ueber die
*Bedeutung* der mittels "Verzeichnissen" eingerichteten Struktur
im klaren sind (bzw. sich darueber verstaendigen). Versionskontrolle
ist ein (im Uebrigen auf weitestgehende "Schmerzfreiheit" optimiertes)
Werkzeug, besonders gut laesst es sich aber erst nach dem Verinnerlichen
geeigneter Paradigmen einsetzen (siehe aber auch Maslow's hammer).

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAkyPN5UACgkQYhMlmJ6W47NSqwP/btG2tLlCBd3kbRYiVZ2BFvwZ
+wy9mg9W5aIyO05X3Z++Tnjq0p0NI1M8HTGRZYdWKj+tZLzN8x38pOFb1vP7+unY
c4D8Me3KP5j+YiS0fs+qS0O3Y12gnEb1dAQIIDtH3VU9rEMhWjmZMIuvqhLa0csR
wTRrfh0iyUCjS+Jyl80=
=jqTw
-----END PGP SIGNATURE-----