[Allegro] Subversion

[Thomas Berger]

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

Lieber Herr Eversberg,


>> die sich aber dennoch lohnt.
> Das eben ist sehr die Frage. Summa summarum verneinen wir sie, denn es
> kommt ja hinzu, daß man sich um die Einbindung in die Programmlogik
> noch zusätzlich kümmern muß!!! Das bliebe natürlich an uns hängen.

Ich hatte (diesmal) gar nicht vorgeschlagen, dass (ebenfalls kein neues
Desiderat) PRESTO und a99 etc. eine elaboriertere Suchlogik fuer
benoetigte Dateien bekommen.


>> [1] verlinkt von http://www.gymel.com/acrules/, wo steht:

Das Dokument organisiert alle Dateien aus inst-all.exe nach
Funktionszusammenhaengen, ist also etwas rein intellektuelles.
Software zur Versionskontrolle kann dabei nicht viel helfen
(svn kann im Gegensatz zu CVS allerdings auch Umbenennungen/
Verschiebungen nachvollziehen, insofern kann ich eine eher
amorphe Sammlung importieren und nach meinem Gusto umstrukturieren).


>> Das Installationsarchiv inst-all.exe für Version 25 etwa entpackt 1050
>> Dateien in diverse Unterverzeichnisse. Erfahrungsgemäß ist es oft
>> schwer, nachzuvollziehen,
>>
>>     * welche Dateien zu allegro-c "an sich" gehören, oder zum
>>       Standardschema $A.CFG oder nur zur Demodatenbank oder reine
>>       Beispiele sind.
> Restlos bereinigen läßt sich das per Versionskontrolle auch nicht.
> Seit langem schreiben wir aber in die Dateien rein, wozu sie sind, und
> das Entstehungsdatum. Sowas zeigt VNC auch nicht.

Na: Meinen Sie etwa den Anfang von d-1.apr?

  D-1.APR  Anzeigeparameter Standard fuer A.CFG
  980406/000503/010320   Ueberarbeitung fuer V15e/V20/V21
  980420      viele Ergaenzungen und Verbesserungen von Winfried Goss
pn="ANZEIGE V20"
  OPAC:  Start mit -Uai0  um bestimmte Aenderungen einzuschalten!
  2003-02-28 : V23 : Unicode

Die aktuelle Datei ist vom 5.7.2007 und seit dem 28.2.2003 hat es
diverse Aenderungen gegeben. Die automatisch eingesetzten Tags ($Id: $
vor allem) sind hilfreich, weil sie im Gegensatz zu menschengemachten
Dateikoepfen immer aktualisiert werden.


>>     * mit welchen Dateien man eigene Installationen regelmässig
>>       unbesehen (d.h. unangepasst, nicht ungetestet) aktualisieren
>>       sollte.
> Das hängt sehr von lokalen Gegebenheiten ab, erfordert also Kenntnisse,
> die VNC nicht haben kann.

Genau: Daher fliessen diese Kenntnisse in die menschengemachte Struktur
ein.


>>     * welche Dateien man benötigt, um ein gewüschtes Feature in eine
>>       eigene Anwendung einzubauen
> Ist nicht Sache einer Versionsverwaltung und wird durch Verzeichnis-
> Verschachtelungen nicht erleichtert.

Na und ob: allegro-HANS und allegro-NRW sind z.B. zwar beide nicht
im A-Schema, nutzen aber alle Komponenten eines unabhaengig
installierten Standardallegro, die schemalos Sinn machen (Hilfesystem,
UIF-Dateien, viele Flexe). Der jeweilige Installer weiss genau,
welche Dateien zu welchen "packages" gehoeren und kopiert eine
von mir definierte Liste von "packages" aus dem Standard-Allegro
in die Zielinstallation. Andere "packages" (z.B. die oninput-Mimik)
kommen mit dem Installer selber. Anders geht es m.E. gar nicht,
weil ich ja nicht riskieren kann, dass ein $A-spezifischer oninput.flx
aus inst-all.exe zufaellig einmal neuer ist als der von HANS und
sich in die HANS-Installation schmuggelt.



>>     * welche Dateien von Release zu Release neu, umbenannt oder
>>       verschwunden sind
> Das löst VNC auch nicht.

Ich verbringe jedes Jahr viele, viele Stunden damit, inst-all's zu
installieren und zu analysieren, welche Dateien neu sind, verschwunden
sind oder "nur" umbenannt. Das ist einer der nervigeren Aspekte meines
Berufslebens.

>> Als ersten Schritt in Richtung auf eine Lösung der oben angesprochenen
>> Probleme gibt es ein Strukturbeschreibungsdokument, das alle Dateien aus
>> inst-all.exe nach inhaltlichem Zusammenhang zu gliedern versucht.
> Es gibt aber, wie Sie selber andeuten, nicht immer eine eindeutige
> Zuordnung in einen Zusammenhang!
> Aber gesetzt, man hätte das einmal geleistet. Hernach müßte man dauernd
> noch *zusätzlich* drüber nachdenken und entscheiden, wo man eine neue
> Datei einordnen sollte.

Ja! Ja! Ja!


> Man muß *zusätzlich* *jedesmal* den
> Verzeichnisnamen tippen oder klicken, ihn *zusätzlich* *jedesmal*
> aufschreiben und erwähnen, wenn es um die Datei geht, usw. usf. Das ist
> jetzt doch alles viel einfacher.

Nun, aus Anwendersicht bleibt alles ja beim "bewaehrten" einfachen
Verzeichnislayout. Und da muss man den Verzeichnisnamen eigentlich
nie angeben, weil anhand der Extension normalerweise das Verzeichnis
eindeutig ist.

Aus Entwicklersicht muss man einen Verzeichnisnamen ausdenken, der
die Funktionalitaet halbwegs trifft (etwa "hilite" fuer das Tripel
hilite.apr, hilite.flx und hilite.rtf, das das in v24.0 eingefuehrte
"Syntax-Hilighting fuer Parameterdateien" realisiert). Alles, was
ich dann in einem gegebenen Kontext brauche, liegt im "aktuellen"
Verzeichnis, das kann ich mir auch gut merken.
[Nebeneffekt waere allerdings wahrscheinlich, dass Verlinkungen in ganz
andere Zusammenhaenge in den RTF-Dateien etwas muehsamer werden, das
sehe ich aber nur positiv].

Auf dem Expertentreffen hatte ja eine Diskussion darueber begonnen,
was denn der "Kern" von allegro-C ist. Zu DOS-Zeiten bestand der
aus den Executables, UIF-Dateien und einer ueberschaubaren Zahl
von Hilfeseiten. Mit a99 liegt darum eine Schale von schema-
unabhaengigen Flexen (und RTF-Dateien) zur Administration, die
ausfuehrliche Dokumentation und einiges mehr, das meiste davon
ist nuetzlich bis essentiell und sollte ebenfalls als "Kern" angesehen
werden. Anderes (z.B. der "memo"-Mechanismus, ich habe jetzt nicht
nachgsehen, wie schema-unabhaengig er ist) qualifiziert eher als
Demonstration. Daneben gibt es wie zuvor Dateien oder Mechanismen,
die nur im Zusammenhang mit einem konkreten Kategorienschema Sinn
macht, oder sogar ganz eng nur im Zusammenhang mit der Demo-Datenbank.
Gerade hier ist aber besondere Sorgfalt notwendig, denn z.B. oninput.flx
muss so heissen, ist aber hochgradig abhaengig vom Kategorienschema
(genauer: Von der konkreten Auspraegung, die durch Anzeige- und
Indexparameter und Formulardatei gegeben ist].

Ich sehe natuerlich, wie das "jetzt doch alles viel einfacher" ist,
und ich moechte keinen meiner Vorschlaege so verstanden wissen, dass
irgendwelche Lasten auf die Entwicklungsabteilung abgewaelzt werden.
Vielmehr ist es ja so, dass das kontinuierliche Sichten und
Restrukturieren von mir (und vermutlich einigen anderen) schon seit
langem durchgefuehrt wird. Und ich behaupte, dass durch eine Buendelung
solcher Aktivitaeten (durchaus mit der obersten Regel, dass nichts
und niemand der Entwicklungsabteilung Arbeit machen darf) letztendlich
auch Sie entlasten wird.

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

iD8DBQFGrwTahKFJT0F1FsoRAgR2AJ9YYh6vuXMM5zDMjA6mu/FgZNp4hACeOKQI
PRp425EVHvO/19zrS6wB44I=
=+Xkz
-----END PGP SIGNATURE-----