[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