[Allegro] Subversion

Thomas Berger ThB at Gymel.com
Di Jul 31 18:19:25 CEST 2007


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

Lieber Herr Lehmann, liebe Liste,

> nachgedacht: kann ein normaler allegrologe mit einem subv-system was
> anfangen??? habe noch keine antwort darauf, auch was meine person
> angeht....

Lieber nicht "allegrologe" definieren wollen und schon gar nicht
"normal". Subversion ist nach eigener Auffassung ja auch nur eine
DAV-Applikation (Distributed Authoring and Versioning). "Authoring"
ist klar, man kann schreiben. "Versioning" ist die Konsequenz,
wenn mehrere unabhaengig voneinander schreiben duerfen. Vom
"Versioning" profitieren auch jene, die nur lesen wollen, weil
sie Versionen vergleichen koennen. Dazu muss man allerdings
(Parameterdateien, Flexe, ...) lesen koennen. Vielleicht ist das
eine gute Definition der Grenze zwischen Anwender und Allegrologen
(frueher waren wir vermutlich ambitionierter und setzten das
"schreiben koennen" als Grenze).

Also:
(1) Jemand der sehen will, was in einer durch ihn benennbaren Datei
    zwischen Zeitpunkt x und Zeitpunkt y passiert ist, hat tendenziell
    einen Nutzen dadurch, dass er ein Versionskontrollsystem lesend
    konsultieren kann (ich muss mir selbst staendig Fragen beantworten
    wie "seit wann existiert Feature xy" oder "Wann ist z kaputt
    gegangen").

(2) Egal ob "auschecken" sofort einsetzbare Dateien liefert oder
    noch zu verarbeitende (weil die Verzeichnisstruktur nicht "stimmt"
    oder noch Verarbeitungen durchzufuehren sind), mit einem
    oeffentlichen Repository sind ja 90% der Vorarbeiten getan, um
    auch aktuelle Downloads fuer Endanwender zu produzieren und
    bereitzustellen.
    [Ich habe das frueher einmal manuell getan:
     < http://www.gymel.com/patches/ >, das mangels Resonanz aber
    nicht fortgefuehrt]

(3) Schreibzugriff ist mit Verantwortung verbunden, man sollte
    sich vorher auch Grundkenntnisse aneignen, was Versionskontrolle
    ist und was das konkrete System kann und mag (Versionskontrolle
    "mag" zum Beispiel nicht, wenn man eine inhaltliche Aenderung
    einbringt und gleichzeitig flaechendeckend Kommentare "verschoent").
    Man wird sich diese Disziplin also nur zumuten, wenn man zu
    ungeduldig ist und nicht darauf warten mag, dass jemand anderes
    das tut, von dem man denkt, dass es eigentlich getan werden sollte.

(4) (Weil allegro-Parameterdateien direkt aenderbar sind, und weil 64kB
    Parameterspeicher sehr wenig sind: ) Allegro bietet nur sehr
    rudimentaere Mechanismen zur Laufzeitkonfiguration. Fuer nur
    minimale anwenderspezifische Anpassungen (z.B. Eingriff in die
    Signaturaufbereitung #(O ) muss eine der zentralen Monsterparameter-
    Dateien richtiggehend umprogrammiert werden. Das bedeutet, dass man
    bei allegro staerker als anderswo auf "Branches" oder komplett
    geklonte Projekte zurueckgreifen muss. Im Prinzip kann daher ein
    eigenes Versionskontrollsystem fuer jeden Systembetreuer an
    sich schon von grossem Nutzen sein (man lese nur die unermuedlichen
    Mails von Herrn Fischer aus Goettingen), umgekehrt bedeutet das aber
    auch, dass eine Infrastruktur (aus einem oder mehreren
    Repositories), in der mehr als eine Person agiert, eine groessere
    Komplexitaet hat, als "klassische" Anwendungen (mehrere Entwickler
    pflegen im Wesentlichen ein "Produkt").

(5) Kaskadierung ist immer mit Komplexitaet verbunden: Im Bereich
    der Normdatennutzung gibt es mehrere bekannte Modelle, in
    Deutschland wurndert man sich, welchen Krampf die Amis machen,
    aber auch hier fragen sich die, die es geschafft haben, direkt
    in die PND schreiben zu duerfen, wie sie die frueheren Prozederes
    mit offline-Meldeverfahren, zwischengeschalteten Subredaktionen
    etc. haben aushalten koennen ohne wahnsinnig zu werden.
    Uebertragen heisst dies, wenn man ein Repository *systematisch*
    nutzt (und sei es nur, um ein eigenes regelmaessig zu updaten)
    entsteht oft der starke Wille nach Schreibrechten (es gibt arch und
    svk als noch abstraktere Loesungen, um Repositories sternfoermig
    miteinander zu verkoppeln, das habe ich aber nicht zum laufen
    gebracht und ist vermutlich im allegro-Zusammenhang definitiv
    overkill).

viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGr2ENhKFJT0F1FsoRAv1JAJ4jEEKBEqxIEjn0Uitt0g4qQHqygACfdpMv
nIAwxsldy3Ot4SJ1L5qZ9UY=
=aqvY
-----END PGP SIGNATURE-----



Mehr Informationen über die Mailingliste Allegro