[Allegro] ac15, aindex, osdp etc.: Noch was

[Thomas Berger]

Lieber Herr Eversberg,

>>>> beheimatet ist, ist dadurch nicht erklaert (es sind halt "historische"
>>>> Gruende, aber das haben wir vor ein oder zwei Jahren hier gruendlich
>>>> durchdiskutiert)
>>>>
>>>
>>> Ja gut, dann erklären Sie, wie man es besser machen sollte, und
>>> machen Sie es (sofern wir einverstanden sind).
>>
>> Da kann man wenig bis nichts machen, wenn man die angesammelten
>> Versionsinformationen beibehalten will ...
> 
> Also wir könnten drauf verzichten. Wir stehen doch ganz am Anfang mit
> der Versionsverwaltung der Quellen! Was zeitlich davor liegt, ist
> unendlich viel mehr und nur noch in Bruchstücken rekonstruabel, und
> meine Erfahrung damit ist, daß ganz äußerst selten ein Rückgriff auf
> ältere Quellen mal nützlich war, nie aber unverzichtbar.
> Also weg damit, wenn's danach möglich ist, eine bessere Organisation
> umzusetzen und den künftigen, immer wieder aufflackernden Ärger
> mit einem unzureichenden Konzept zu vermeiden. Machen wir doch
> nicht so eine Wissenschaft draus, das artet allzuleicht in Selbstzweck
> aus.
> Oder warum nicht, wenn Sie ein Löschen doch nicht über sich bringen
> können, umbenennen und ganz neue Repos aufmachen, die besser
> organisisert sind? Dann geht nichts verloren, sondern kann ungestört verstauben.

Ich denke, man koennte einige der bislang in getrennten Repositories
gefuehrten Projekte in ein Repository zusammenfassen (weiterhin als
getrennte Projekte), etwa alles was mit C/C++-Quellen zu tun hat.

Das "download"-Repository, der tendenziell ein alternatives Archiv fuer die
Inhalte von inst-all.exe ist, sollte separat bleiben, wegen der vielen
Executables und anderer Binaerdateien ist es derzeit sehr umfangreich und
waechst stark, dafuer muss irgendwann auch eine schlauere Loesung her,
"Online-Dokumentation", "Handbuch-Quellen", "User contributed content" muessen
in diesem Zusammenhang auch noch irgendwann ihren Platz finden.

"demo2" ist interessanterweise nicht ein Unterverzeichnis von "download"
(obwohl: eigentlich logisch: Es ist ja eine Kopie von "demo"), sondern ein
eigenes Projekt in einem unabhaengigen Repository. Keine Ahnung, ob "eigenes
Projekt" hier ueberhaupt hilft.

a30 und phpac sind eigenstaendige Projekte, evtl. kann man sie aber
in ein Repository "offizioese Webpakete" zusammenfassen.

"progs" scheint ein vergangener Versuch von irgendetwas zu sein, "semapp"
gehoert u.U. gar nicht auf diesen Server.

Das "Quellen"-Repository wuerde also das kommende a99-Projekt enthalten
sowie ac15, aindex, acon, atools, avanti, osdp sowie die noch ausstehenden
ztarget und zc

In einem Repository mit mehreren Projekten besteht nun die Freiheit, eines
der in http://svnbook.red-bean.com/nightly/de/svn.reposadmin.planning.html
skizzierten Organsisationsmodelle anzulegen. Das meistverbreitete waere

acon/
  trunk/
  tags/
  branches/
ac15/
  trunk/
  tags/
  branches/
aindex/
  trunk/
  tags/
  branches/
atools/
  trunk/
  tags/
  branches/
...

ein Alternatives waere

trunk/
  acon/
  ac15/
  aindex/
  atools/
  ...
tags/
  ...

das wuerde aber die Trennung in verschiedene Projekte in der Praxis
weitgehend aufheben und waere eigentlich dann nur noch ein Riesen-
allegro-Projekt mit Quellen in Unterverzeichnissen. Das ist im Prinzip
in Ordnung, aber da nicht alle Teile auf allen Plattformen verfuegbar
sein werden (etwa nicht a99 unter Solaris) wuerde das Irritationen
geben.

Es spricht nichts dagegen, auf einer Uebergeordneten Ebene noch
einmal zu differenzieren, etwa

Modules/
   ac15/
      trunk/
      tags/
      branches/
   aindex/
      ...
   acon/
   a99/
   atools/
   ...
Utilities
   avanti/
      trunk/
      tags/
      branches/
   zc
      trunk/
      tags/
      branches/
Toolchains/
   MSVC/
      Acon/
         trunk/
         tags/
         branches/
      Atools/
      ...


(Interaktion von "avanti" mit "allegro" besteht derzeit ja nur
darin, dass sowohl avanti als auch acon die .conf-Datei lesen
koennen, daher ist avanti fuer mich ein Utility in der Art eines
Wrappers, der acon http-Faehig macht)

"Toolchains" sind die dieser Tage diskutierten Projekte (im IDE-
sinn, nicht im SVN-Sinn), die andere Teile des Repositories
einbinden werden, so dass eine konkrete Gruppe von Programmen
auf einer konkreten Plattform compiliert werden kann.

Komplexere Module wie acon werden u.U. irgendwann auch selber
Unterverzeichnisse haben (ich denke an eine integrierte Testsuite,
damit nach der Kompilation durchs Makefile zumindest die
grundlegende Funktionsfaehigkeit abgeklaert werden kann).

Die Frage wird auch irgendwann sein, ob man Flex- bzw. Job-Doku
im Zusammenhang mit den Quellen der Executables ablegt oder
als separates Projekt, im "Quellen"-Repository oder im "inst-all"-
Repository.

Da die Eroeffnung eines zusaetzlichen Repositories fuer a99 ohnehin
bevorsteht, waere es vielleicht wirklich eine gute, evtl. sogar die
letzte Gelegenheit, das als "allegro" oder "quellen"-Repository
gemaess obiger Struktur anzulegen, a99 dort an seinen Ort initial
einzuchecken und den aktuellen Stand der erwaehnten anderen a*-
Repositories dorthin zu kopieren (ohne dass sie ihre History mitnehmen,
da ja Repository-Grenzen ueberschritten werden).

viele Gruesse
Thomas Berger