[Allegro] Versionskonrolle allegro

[Thomas Berger]

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



Am 21.08.2010 21:20, schrieb Andreas Wolf:

> Anando Eger möchte: "Für Allegro scheinen mir eine Reihe relativ
> unabhängiger Repositories sinnvoll". Und genau das ist es. Relativ, da sich
> die Flexe, Hilfetetxte und UIFs mit Sicherheit mit der A-Konfiguration
> überschneiden.
> 
> 
> Wir hätten dann ein SVN (oder git oder was auch immer) Repository für die
> Kernsysteme a99/avanti, ein Repository für die Beispieldatenbank und ein
> Repository für die A-Konfiguration.
> 
> 
> Denn dann müsste ich auch nicht immer die ganzen für mich komplett
> überflüssigen Dateien der A-Konfiguration aus jedem Update herauslöschen
> .... Wir hatten mal die Diskussion, warum ich nicht gerne update ...

Auch *ein* Repository kann verschiedene "Projekte" enthalten (wenn ich mal
in SVN die Anlage der Parallelitaet von "Trunk", "Tags", "Branches" an
einer beliebigen Stelle als Wurzel eines "Projekts" definiere). Und jedes
dieser Projekte wiederum kann ein tief verschachtelter Baum aus Features oder
Komponenten sein. "Normal" duerfte sein, dass Entwickler sich am "Trunk" eines
"Projektes" orientieren bei ihrer Entscheidung, welchen Teil des Repositories
sie lokal halten, groebere und feinere Einheiten gehen natuerlich auch,
entsprechende Leserechte vorausgesetzt.

Typischerweise hat so etwas wenig bis nichts mit dem Verzeichnislayout
der resultierenden Anwendungen (andere Faustregel: 1 Projekt <=> 1 separat
distribuierbare "Anwendung") zu tun, hier fuehrt die derzeitige Struktur
des Braunschweiger SVN-Repositories voellig in die Irre.

Es ist allerdings unendlich schwierig, die einzelnen Dateien einzelnen
Funktionszusammenhaengen zuzuordnen oder nach dem Grad der Universalitaet
auseinanderzuklambuesern: Es gibt fast immer eine allgemeine Dokumentations-
seite, die auf eine schemaspezifische Funktionalitaetsseite verlinkt
oder eine Funktionalitaet x, die aus "siehe-auch"-Gruenden in einem
Menue erscheint, das ueberweigend ganz andere Funktionalitaeten erschliesst.

[Ich hatte vor Jahren (zwischen V24 und V27) einmal solche Strukturierungs-
versuche unternommen, da allerdings mit den Feature- und Komponentenkonzepten
von Windows-Installern im Sinn, im Bereich Parameterdateien und
Dokumentation sind die Strukturierungsgesichtspunkte aber hier wohl
vergleichbar mit denen bei der Organisation eines Quellen-Repositories:
http://www.gymel.com/acrules/v27.html
Ich habe das nach ca. drei Jahren aber abbrechen muessen, Dateien kamen
und gingen, manches wurde vorher angekuendigt, manches erst lange
nach der Auslieferung, Dateien wurden umbenannt, etc. pp: inst-all.exe
enthaelt ja einen wuesten Mix aus stabilen und hochgradig Experimentellen
bzw. nur skizzenhaften Funktionen und nur wenig Hinweise darauf, welche
das eigentlich sind (und ob sie je funktioniert haben). Das retrospektive
(Er-)Finden eines Sinnzusammenhangs fuer alle diese Dateien wurde mir als
Langzeitaufgabe irgendwann viel zu muehsam...

*Ein* Repository hat insgesamt den Vorteil, dass die angemessen feine
Veraestelungsstruktur sukzessive entstehen darf, Dateien werden dann
einfach verschoben, sobald klar ist, wohin sie gehoeren. Mehrere Repositorien
hingegen erfordern, dass jede einzelne Datei gruendlich studiert und ggfls.
abgeaendert werden muss, bevor sie irgendwo aufgenommen wird: Auch keine
schlechte Perspektive eigentlich...

viele Gruesse
Thmomas Berger

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

iJwEAQECAAYFAkxwadAACgkQYhMlmJ6W47NblAP+Kai581hB1bYLJw3N7dZEDHzU
0pA7XQTLxuGf5seLq3GhEhCk61vW3iO0jmNTpCX617UMCZhfFPaAZF9uCE+ggwik
rdeYue6L+1YLFsUG+QTYYy6z7fUqFfyzuPh4j9hrptShBIRMUXmbacUdqVNsYMlK
1ReDbznPZNxvA1UKgFk=
=rI1d
-----END PGP SIGNATURE-----