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

[Thomas Berger]

Lieber Herr Eversberg,

>> 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/
>> ...
> 
> Achtung: acon braucht ac15 und aindex, aber atools nicht, doch das
> scheint ja hiermit auch nicht präjudiziert zu sein.

nein, Projekt ist hier Projekt, egal ob es eine Library oder
ein Executable liefert. Noch weitere Verfeinerung nach Typ
oder nach benutzter Sprache scheint mir wenig Sinn zu machen.


> Ansonsten steht in dem zitierten Text:
> 
>> "... jedoch sind die eigentlichen Arbeitsschritte für die Einrichtung
>> eines Subversion-Projektarchivs recht einfach und neigen zur
>> stupiden Fleißarbeit, falls Sie mehrere davon aufzusetzen haben."
> 
> Die Lösung sollte so wenig stupide wie möglich sein, das versteht sich

In der deutschen Uebersetzung des Subversion-Buchs ist "Subversion-
Projektarchiv" das, was wir hier Repository nennen (also eben kein
Einzelprojekt, sondern ein Archiv fuer Projekt*e*).


> für mich von selbst: Die Werkzeuge sollen nicht zum Selbstzweck mutieren
> und den Entwickler versklaven. Und keine vorerst überflüssigen Dinge
> wie Hook-Skripte und solche Sachen, um die man auch noch zu wissen und
> sich zu kümmern hätte. Sie verlieren mir allzuleicht die Ökonomie aus
> den Augen, werter Herr Berger!

Nun, da ich nicht Ihr Serveradministrator bin, komme ich auch nicht
in die Verlegenheit...


> Und wo Versionierung keinen unbestreitbaren Sinn ergibt, da sollte man
> wohl drauf verzichten. D.h. das Repo "download" sollte wohl besser
> erstmal ersatzlos verschwinden - die "Gesamtpakete" bilden eine
> natürliche Generationenfolge und können als solche auch einfacher
> archiviert werden. Wir hatten "download" eigentlich im Unwissen über
> seine Sinnhaftigkeit mehr zum Ausprobieren angelegt.

Nun, fuer Parameterdateien, Flexe, Jobs, Dokumentation im Textformat,
Viewlisten etc. ist SVN ein durchaus geeignetes Werkzeug, den Stand
der jeweiligen Gesamtpakete etc. zu archivieren und vergleichbar zu
halten. Ablage der gepackten inst-all.exe's ist nicht annaehernd so
fruchtbringend. Bei Executables und RTF-Dateien, die bei jeder Bearbeitung
alle Styles neu durchnumerieren, wo also jede noch so kleine Bearbeitung
Aenderung in jeder Zeile der Datei nach sich zieht, ist eine Quell-
Verwaltung natuerlich keine grosse Hilfe. Ich moechte aber ganz
energisch davon abraten, das "downloads" repository nicht weiterzufuehren,
bloss weil seine jetzige Form nicht optimal ist.

viele Gruesse
Thomas Berger