Empfehlungen zum Aufbau von Repositories

Konventionen
1

Wenn ich die aktuellen Repositories anschaue, dann gibt es verschiedene Strukturen, um die aktuellen und die alten Modelle abzulegen.

Zum Beispiel:
https://models.geo.admin.ch/ mit ilisite, ilimodels und ilidata.xml

Dann die aktuellen Modelle z.B. der Swisstopo:
https://models.geo.admin.ch/Swisstopo/

und dann in einem Folder replaced
https://models.geo.admin.ch/Swisstopo/replaced/

Daneben gibt es aber auch noch
https://models.geo.admin.ch/obsolete/

Was ist da der Unterschied zwischen replaced Modellen und obsolete Modellen?
So wie es scheint scheinen beide Ordner und alle Modelle im ilimodels drin zu sein.

Beim VSA gibt es den Hauptordner
https://www.vsa.ch/models/ mit ilisite, ilimodels und ilidata.xml

Und dann Release Subordner
https://www.vsa.ch/models/2020/

Und dort drin die PrecursorVersion
https://www.vsa.ch/models/2020/precursorVersion/

Und dort drin dann noch einen Subordner old mit den Vor-vor-Versionen:
https://www.vsa.ch/models/2020/precursorVersion/old/
Diese sind aber dann nicht mehr im ilimodels aufgelistet

Wie weit soll ein Repository im ilimodels.xml alte Modelle noch auflisten und ab wann sind sie einfach einem „Archivordner“ noch verfügbar?
Dass alte Modelle noch verfügbar sind, scheint mir sinnvoll, weil es immer noch alte Daten gibt. Aber wie weit soll ab einem bestimmten Zeitpunkt auch irgendwie gezeigt werden, dass dies alte Daten sind und die automatische Prüfung via Repo nicht mehr unterstützt werden?

Pro:

  • Falls alle Modelle in ilimodels drin sind, kann nach ihnen automatisch gesucht werden
  • Bestehende Dienste laufen weiter, auch wenn eine Neuerung publiziert wird

Con:

  • Die Pflege des ilimodels.xml ist sehr aufwändig, weil die ganze Hierarchie von Pre-Pre-Precursorversions gepflegt und nachgeführt werden muss. Vorallem wenn es mehrere Stufen von Subordnern gibt oder ein precursorVersion/replaced und ein obsolete/old

Was meinen andere Repository Verantwortliche zu diesen Fragen?
Wie handelt ihr das?
Wären Empfehlungen hier hilfreich?
Welche Prozesse müsste hier der ilimanager (zusätzlich) unterstützen?

2 „Gefällt mir“
2

Wir machen es maximal unelegant: Gibt es eine neues Modell, bekommt es einen neuen Namen. Dabei hängen wir einfach das Datum als Suffix an: „SO_AFU_Geotope_20190211“ wird zu „SO_AFU_Geotope_20200312“. Die Modelle kennen sich nicht, d.h. es wird keine Precursor-Version gesetzt. Die alten landen in einem „replaced“-Ordner. Modelle im „replaced“-Ordner erscheinen nicht im ilimodels.xml.

Die Modelle sind alle noch verfügbar, halt einfach nicht mehr automatisch. Aber ich glaube - so elegant das mit den Versionen und Precursor-Gedöns ist - es überfordert die Anwender und die Betreiber. Mit unserer hässlichen Lösung hast du in your faced den Namen des Modelles und das Werkzeug funktioniert mit Daten im alten Modell nicht mehr automatisch.

Wenn man mit PrecursorVersion und gleichen Modellnamen arbeitet, dürfte man das wohl sowieso nicht mehr händisch nachführen. D.h. du müsstest entweder eine klare Logik haben, die du immer befolgst (damit die Maschine das XML machen kann). Also z.B. Version als Datum, Reihenfolge ist durch Datum bestimmt. Oder du führst in den Modellen ein Metaattribut ein, welches dein Tool ausliest und so die Precursor-Version setzt.

Für eine geschlossene, kleinere User-Gruppe oder einen bestimmten Anwendungsfall würde ich aber die Sache schon nicht verteufeln wollen. Als 08/15-Repo für alle: zu kompliziert.

3

zu replaced<>obsolete-Frage: im Zusammenhang mit der Crawler-Funktion hinter ilimodels.ch haben wir von Rolf Zürcher/KOGIS den Input bekommen, dass \obsolete-Verzeichnisse teilweise sogar ungültige Modelle enthalten und daher beispielsweise auch von der Modell-Suche ausgeschlossen werden.