ich bin dabei etwas zu machen, um meine IPS-Scripte unter Versionskontrolle von git zu setzen, weil es ja schon praktisch sein kann, nachschauen zu können, was man so geändert hat.
An sich ja kein Problem. ich wollte dann auch gleich (wie bei Modulen) StyleCI benutzen, auch kein Problem … aber:
sowohl die Legacy- als auch die Web-Console speichern die Dateien mit Zeilenumbruch+Zeilenvorschub (CR+LF). StyleCI ändert das in Unix-Format (nur LF).
PHP ist das egal, der verarbeitet beides.
Das Problem ist nun, das nach jeder Änderung durch die Console immer die ganze Datei in git als geändert gilt, weil ja eben durch die Console immer jedes LF durch ein CR+LF ersetzte wird und durch StyleCI zurück.
Unschön.
Ich kenne keine Möglichkeit, der Console das Verhalten abzugewöhnen und habe auch keine Option gefunden, notfalls StyleCI dazu zu bringen, das zu unteröassen (wobei ich das Unix-Verhalten schon aus Gewohnheit lieber hätte).
Mein Fehler: ich habe nach dem ‚git config‘ die anderen Befehle nicht / nicht vollständig durchgeführt und dann hat das auf bereits vorhandenen Dateien keine Auswirkung - auch nicht bei neuen Änderungen
Jetzt scheint es zu funktionieren.
Allerdings ist mir noch ein Problem aufgefallen: es wäre schon potentiell problematisch, wenn IPS-Script etc in einem öffentlichen git-Repository stehen würden - könnten ja durchaus persönliche Daten drin stehen.
Also entweder ein privates Repository auf GitHub, besser natürlich einen lokalen git-Server einrichten - habe ich sogar schon auf meine Synology laufen.
Dann ist StyleCI nicht mehr möglich; schade, zu mindestens bei größeren Script trägt das ja schon zu einer besseren Lesbarkeit bei.
Die Scripte enthalten ja u.U. soviel für IPS relevante Logik, das vermeintlich kleine Änderungen durchaus zu größeren Such-Aktionen führen können. Alleine die settings.json reicht (mir) nicht aus, ist auch, weil das ja auch die aktuellen Werte drin stehe, nicht ganz so einfach zu diffen - ich müsste bei jedem Objekt aus der Struktur „data“ die Felder „value“, „lastUpdate“, „lastChange“ ignorieren.
Nur damit ich nicht in etwas Arbeit hineinstecke, was bei euch ggfs. auf der Agenda ist: ihr plant nichts in dem Bereich?
Man kann das lf Verhalten auch in .gitattributes steuern. Der folgende Eintrag erzwing das Unix Zeilenende bei jedem push/pull
# perform LF normalization
* text=eol=lf
persönliche Angaben sollte man auch nicht an Github schicken, sondern entweder in einem include auslagern was durch die .gitignore nicht an Github übertragen wird oder man macht sich einen Branch für Github mit Dummy Daten und einen 2. Branch mit dem man arbeitet. Mit git merge lassen sich die Änderungen auch gut syncronisieren.
Aber so toll ist StyleCI nun auch wieder nicht, das man auf ein lokales Repository oder lokales Gitlab verzichten sollte.
Warum soll man sich einen fremden Style aufzwingen lassen, wenn man nicht dafür bezahlt wird. Wichtiger als die Form ist sowieso der Inhalt - und ein effektiver Workflow.
Ich denke, die IPS Roadmap ist voll genug und Versionsverwaltung schon ganz gut durch Standardlösungen abgedeckt.
das war auf keinen Fall so gemeint, das ich damit anregen wollte, das auf die IPS-Roadmap gesetzt wird, sondern rein die Frage, ob es da irgend eine Planung gibt.
ich habe an dem Thema weitergearbeitet und habe ein Modul geschrieben, was die IPS-Konfiguration unter git-Kontrolle sichert.
Das sind natürlich besonders die Script, aber auch alle IPS-Objekte sowie auch die installierten Module.
Der Webfront-Bereich wird noch nicht gesichert, wird aber noch dazu kommen.
Das Script kann ohne weiteres stündlich laufen, sodaß auch bei häufigen Änderungen die Übersicht erhalten bleibt, was geändert wurde.
Du könntest die Module „weglassen“ und nur die URLs und CommitIDs von den installierten Modulen speichern. Unter der Prämisse, dass ein Entwickler seine Module nicht löscht, reicht das vollkommen aus um den Zustand wiederherzustellen.
Ich mag deine Idee, alles auf einzelne Dateien zu erlegen. Folgende Ideen hatte ich dazu mal:
Wenn du die settings.json zerlegst, anstatt die IPS_* Funktionen zu verwenden, könntest du diese einsparen und wirklich nur die Änderungen commiten (natürlich ohne Zeitstempel/Werte). Das würde weniger Rauschen auf dem Repo erzeugen. Natürlich mit dem Nachteil, dass die letzten Werte/Zeitstempel ggf. fehlen. Ein kleines Skript kann die settings.json aus den Einzeldateien wiederherstellen.
Man könnte die Baumstruktur als Dateinamen ablegen. Da Git „Renames“ erkennt, könnte dies klappen und es sehr leserlich werden.
Es gibt mehr als nur die Zeitstempel, die sich periodisch ändern können. z.B. können viele User Ihre Objekte periodisch sichtbar/unsichtbar machen. Ich habe noch keine gute Idee, aber evtl. müsste man eine „.ipsignore“ anbieten, wo genau diese Ausnahmen definiert werden können.
Wie schaut es mit der DB aus? Dort kannst du ganz entspannt alle Unterordner absichern, da wir ausschließlich abgeschlossene Datensätze abspeichern. Die Aggregation würde ich nicht sichern.
Da du erst ab der 5.0 dein Modul zur Verfügung stellst brauchst du fast alles aus der commons Datei unter libs nicht. Außerdem sind zumindest die Konstanten ebenfalls in deiner module.php drin
Das habe ich auch: ich erstellen zu jedem Modul auf jeden Fall eine json-Datei, die die Git-URL, den gewählten Branch und den Zeitstempel (der letzten Änderung in einem Modul) enthält.
Die Zip-Datei ist ja optional und schon ein bisschen wie „Hosenträgen und Gürtel“, aber nicht ganz. Z.b. kann es ja sein, das es zu einem „komischen“ Verhalten kommt und man hat ein Modul aktualisiert. Mit dem Zip-FIle kann man dann notfalls mal eine ältere Version eines Moduls wieder installieren.
Grundsätzlich hast Du natürlich recht, man kann anhand der Commit-ID’s das auch wieder herstellen, aber da muss man schon genau verstehen, wie man das in git macht …
Ich hatte erst nur die settings.json als Basis genommen. Aber es gibt ein klitzekleines Problem: die settings.json wird ja (typischerweise) nur alle 10 Minuten geschrieben, d.h. ist nicht immer ganz aktuell. War vielleicht mehr ein akademisches Problem, aber bei meine Tests musste ich immer die 10 Minuten warten, bis ich prüfen konnte, ob die Änderungen geschrieben wurden und das war mir zu langweilig und bin daher in die Richtung gegangen, die Objekte direkt auszulesen.
Dann ist man ja auch auf jeden Fall auf der sicheren Seite.
Grundsätzlich schreibe ich die Daten nur, wenn sich inhaltlich etwas geändert hat, damit der Zeitstempel der Datei gleich der letzten Änderung ist. Und damit ist auch nur das zu comitten.
Eine settings_nodata.json (also ohne Daten) hatte ich am Anfang auch erzeugt, aber den Code erstmal wieder tot gelegt.
Ja, eine interessante Idee. Meinst Du, die Struktur als Verzeichnis-Struktur darzustellen (also als Verzeichnisbaum analog zu dem IPS-Baum oder flach, d.h. flach der Dateinamen des Objekts einhält den Verzeichnisbaum?
Ich würde auf jeden Fall sowohl die Objekts-ID und den Namen verwenden (per Hardlink).
Bei Namen habe ich nur das Problem, das man bestimmte Zeichen ausfiltern muss. SO müsste man den Backslash, der im IPS ja für die Verzeichnisstruktur verwendet wird ersetzen - weil das bei Windows ja der Verzeichnistrenner ist und ausserdem (bei Linux) ggfs. als Escape-Character interpretiert wird.
Mit dem Git-Rename muss ich noch etwas probieren, weil ich nicht genau weis, wie das funktioniert (ich stehe mit git etwas auf Kriegsfuß).
Ich lösche zZt neben den Zeitstempeln und der Variablenwerten auch die ChildrenIds. Über so eine .ignoriere-Liste denke ich mal nach …
ja, stimmt, bau ich ein.
Das mit dem Erstellen der ZIP-Datei ist ja kein Problem, allerdings habe ich ein kleines Problem, festzustellen, ob sich was geändert hat. Ein Vergleich von zwei zip-Archiven gibt ja immer ein Unterschied. Ich bin bei den Modulen daher dazu übergegangen, das ich vorher die Zeitstempel aller Dateien prüfen und mit den Zeitstempel des Archivs vergleiche und wenn sich da was unterscheidet, gehe ich von einer Änderung aus. Das ist natürlich nicht 100%-ig, weil man ja grundsätzlich auch Zeitstempel manipulieren kann, aber wenn das jemand macht wäre das ja schon schräg …
Ich wollte auch noch den webfront/user-Ordner optional sichern und der Vollständigkeit halber auch den skins-Ordner.
Wobei ich keine Skins habe und gar nicht weis, wie das aufgebaut ist. Ich meine gelesen zu haben ähnlich wie die modules Müsste ich mir mal ein Skin installieren …
Das stimmt, ich habe mit so ein Muster-Modul gemacht und das war für 4.4. Könnte ich mal aufräumen. Ja und mit doppelt in common.php und module.php ist natürlich auch richtig. Ist auch etwas historisch, weil ich mich erst später entschlossen hatte, eine common.php mit ein paar Standardfunktionen zu machen und bei allen meinen Modulen zu verwenden.
Was in IPS noch fehlt sind meines Wissens nach Konstanten für die Variablen- und Objekt-Typen, korrekt?
Das ist kein Problem.
In der Repro URL beim Modul-Control funktionieren auch URLs mit CommitIDs.
Dann wird genau der gewünschte Commit geclont.
Michael
Vom Gefühl her präferiere ich ja die Verzeichnis Struktur. Dort kann man dann schöner navigieren. Das Filtern der Namen sollte kein Problem sein - der voll Name steht ja weiterhin drin. Die Dateinamen könnten ja Name.ObjektID.json sein.
Da die Daten für die Kategorien ja irgendwie auch gespeichert werden müssen, müsste dafür noch eine Datei her. Diese würde ich im Ordner ablegen in z.b. einer .irgendwas Datei.
Renames erkennt git automatisch.
Die ChildrenIDs sind in der settings.json gar nicht drin.
Du kannst übrigens auch IPS_GetSnapshot verwenden, wenn du nicht an die 10 Minuten gebunden sein willst. Dort sind jedoch ein paar Meta-Daten mehr drin, die du filtern willst.
timestamp
timezone
compatibility
isLocked bei Variablen
nextRun bei Ereignissen
crc bei Medien
size bei Medien
isAvailable bei Medien
war mir nicht bewusst, das es Module gibt, die nicht im Git abgelegt sind … aber klar, warum nicht.
hmm, für die könnte ich natürlich das zippen wieder reinnehmen, Skins dito.
Noch mehr Ideen Ich hatte überlegt, ob es theoretisch möglich wäre eine .gitmodules zu pflegen, die die Repos in „modules“ abbildet. Dadurch dürfte man beim Checkout des „Config“ Repositories recht einfach alle Module in der richtigen Version laden können.
hmm, kenne ich (noch) nicht. Fix mal das internet bemüht…
Das ist also eine Datei innerhalb des jeweiligen Moduls … oder hattest du an ein .gitmodule in dem übergeordneten module-Verzeichnis gedacht?
Die Informationen habe ich ja ( git-url, der branch und die commit-id ), insofern bestimmt machbar, aber mir ist der Nutzen noch nicht ganz klar.