[Allegro] Subversion

[Bernhard Eversberg]

Thomas Berger schrieb:
> 
> Ich hatte (diesmal) gar nicht vorgeschlagen, dass (ebenfalls kein neues
> Desiderat) PRESTO und a99 etc. eine elaboriertere Suchlogik fuer
> benoetigte Dateien bekommen.
Weil Sie wissen, daß es das nicht geben wird.

> 
>>> [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.
So etwas sieht im ersten Moment immer eindrucksvoll aus.
Im zweiten merkt man, daß man so etwas auch nicht als Ganzes überblicken
kann, und daß man die meisten der hier mitgeteilten Fakten nie wissen
muß. Standardanwender _wollen_ auch gar nicht so viel wissen.
Ambitionierte Anwender wollen genau die Dateien schnell überschauen
können, an denen sie evtl. mal was modifizierne, und an die kommt
man über "Info zur Datenbank" und "Füllhorn/Administration" sofort ran
und ohne Umschweife, ohne ihre Namen und Standorte wissen zu müssen!
Solche Hilfen halten wir für VIEL wichtiger, dafür treiben wir gerne
einigen Aufwand.

> 
> 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
Da stehen Name und Entstehungsdatum. Von einer vollständigen Liste
der Modifikationsdaten hatte ich nichts gesagt! Die wäre in diesem
Fall länger als die Datei selbst und schösse damit erheblich
über jedes nützliche Ziel hinaus.

> 
>>>     * 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).
Ja gut, für solche Zwecke kann Ihre Übersicht in der Tat Hilfestellung
leisten. Man KANN aber auch, ohen Schaden zu leiden, zuerst die 
Standard-Installation komplett kopieren und dann Zug um Zug einzelne
Dateien, die man modifziert, in das DbDir übernehmen. Dann braucht man
bei einem Update i.d.R. nur selten irgendwas nachzuvollziehen, was sich
in den Standarddateien getan hat. Erst mal schauen, wie es läuft, und
nur wenn nicht, dann analysieren.

> 
>> 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!
> 
Aber nun haben Sie ja bereits eine Einteilung getroffen. Wenn wir neue
Dateien rausbringen, wird das in der Liste bekanntgegeben. Sie können es
dann Ihrem Gerüst zuordnen.

> 
> 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).
Nein, so tief werden wir nicht verschachteln wollen. Jede mehr als
zweistufige Schachtelei artet in nervige Klickerei aus, und mal
sieht man wieder das eine, mal das andere nicht bzw. übersieht das
dritte, weil es noch woanders liegt. Modularisierung, Hierarchisierung,
Klassifizierung von Dateien muß sich in GANZ engen Grenzen halten sonst
wird sie unversehens zum Selbstzweck und verschlingt für sich selber
zuviel Zeit.

> 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].
> 
Aber wie gesagt, solche Betrachtungen müssen den Normalanwender
überhaupt nicht kümmern! Ob da ein paar Dateien mehr herumliegen,
ist doch heutzutage egal. Was wissen Sie denn, wieviele Dateien
bei irgendwelchen zeitgenössischen Anwendungen herumliegen, die
kaum einer je braucht! Sortieren Sie die auch alle aus?

> 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.
> 
Das betrachte ich noch nicht als erwiesen, sondern erst einmal als
schöne Theorie. Dazu müßten sich andere äußern, die am Ist-Zustand
ein vages Unbehagen empfinden, und müßten an sich beobachten, ob sich
das bessert.

B.Eversberg