git-Struktur für shNG + smartvisu

[mumpf]

Hi,

ich konnte problemlos nach der Komplettanleitung shNG+smartvisu installieren und die Grundfunktionen testen. Bevor ich das Ganze jetzt mit Inhalt versehe, mache ich mir Gedanken, wie man die git-Struktur gestalten sollte. So wie ich das sehe, gibt es verschiedene git-Repositories:

• shNG git
• plugins git
• smarthome git
• autoblind git
• mein eigenes git für das Gesamtprojekt

Wie bringt man das jetzt alles zusammen, damit Updates klappen aber auch Entwicklungen von Plugins bzw. Änderungen an den Original-Sourcen getrackt werden und vielleicht - in ferner Zukunft, wenn ich weiß, was ich mache - mal gepushed werden können?

Mein Gefühl sagt mir, dass jeder shNG-Entwickler vor diesem Problem auch stehen müsste, wie macht ihr das? Derzeit fehlen mir Ideen, über entsprechende Infos/Erfahrungen würde ich mich freuen.

Gruß, Waldemar

[Msinn]

Moin Waldemar,

ich nutze nur zwei der von Dir angeführten Repos: smarthomeNG/smarthome und smarthomeNG/plugins. Parallel dazu nutze ich natürlich die smartVISU (aber ohne git-technische Integration)

Das alte smarthome/smarthome von mknx ist Historie.
Das autoblind (ich nutze es nicht) sollte vielleicht mal in smarthomeNG/plugins einziehen. Es ist für mich nur ein Beispiel für Plugins, die nicht im zentralen Repo sind.

Die Kopplung zwischen smarthomeNG/smarthome und smarthomeNG/plugins per submodule hat sich als problematisch erwiesen, so dass wir die wohl mit der v1.5 von shNG auflesen werden.

An Deiner Stelle würde ich erstmal lokal folgendes tun:

• Ein git clone auf das shNG repo machen (git clone -b $DESTBRANCH https://github.com/smarthomeng/smarthome.git .)
• in das Verzeichnis plugins wechseln
• ein git clone auf das plugins repo machen (git clone -b $DESTBRANCH https://github.com/smarthomeng/plugins.git .)
• Für weitere genutzte Plugins (am Beispiel autoblind): Im Plugins Verzeichnis ein Verzeichnis autoblind anlegen und in das Verzeichnis wechseln.
• ein git clone auf das autoblind repo machen

Nun hast Du alles in einer Verzeichnisstruktur zusammen. So checke ich automatisiert alles aus um die Doku zu bauen. Damit solltest Du auch in den jeweiligen Verzeichnissen für Updates einfach ein git pull machen können.



Für meine Entwicklungstätigkeit habe ich smarthomeNG/smarthome und smarthomeNG/plugins als separate Repos nebeneinander ausgecheckt (das ist dann so nicht ausführbar und dient für mich nur zum pullen/pushen von Veränderungen, die ich dann mit einem Diff Tool mit meiner Entwicklungsumgebung abgleiche. Diese beiden Repos verwalte ich übrigens nicht mit git, sondern mit SourceTree.

[Msinn]

Du kannst für Deine Produktiv-Umgebung über eine Kommandozeilen Option festlegen, in welchem Verzeichnis die Konfigurationsdateien abgelegt werden sollen. Wenn die Option angegeben ist, werden /etc, /logics und /items in diesem Verzeichnis abgelegt.
Das vereinfacht das Sichern der Konfigurationsdaten (z.B. Wenn Du die Konfiguraion in ein lokales git Repo sichern möchtest).

[mumpf]

Hallo Martin,

danke für die Tipps. Ich werde mal in mich gehen. Ich habe zu Hause ein git-Repo, in dem alle meine Entwicklungen landen, die im weitesten Sinne die Hausinstallation betreffen, also:

• shell-scripts, die das initiale Setup unterstützen
• alias definitionen
• scripts, die alles richtig verlinken
• Projekte meiner Entwicklungsumgebung
• natürlich die Konfigurationsfiles (derzeit callidomus, zukünftig dann shNG+smartvisu)
• und sicherlich noch ein paar Sachen, die mir jetzt nicht einfallen...

Bei callidomus habe ich das so weit hin bekommen, dass ich nach der Grundinstallation nur ein Laufwerk mounten muss, dann git clone und anschließend noch ein script laufen lassen muss und ich habe wieder meine produktive Umgebung. So halte ich meine VM (für Tests) und meinen NUC (produktiv) in sync. Ich wollte einfach mal schauen, wie weit ich das auch für shNG+smartvisu hin bekomme.

Nach dem Lesen der git Doku schien es mir das Richtige, mein git Repo führend zu machen und shNG bzw. smartvisu als submodules da rein zu bringen. Jetzt sagtest Du gerade, dass es mit submodules bisher Probleme gab. Erinnerst Du Dich, welcher art Probleme das waren? Ich will natürlich nicht bereits bekannte Fehler wiederholen.

Warum ich glaube, dass es wichtig ist, das vorher zu überlegen: In der Vergangenheit hat es sich (bei mir) gezeigt, dass trotz der vorgesehenen Bereiche für Enduser-Dateien (z.B. configfiles), die nie bei einem Update überschrieben werden, es immer wieder nötig war, auch an den Originalsourcen Änderungen, Korrekturen bzw. Erweiterungen zu machen. Git ist perfekt dafür geeignet, bei einem Update alle Konflikte aufzuzeigen und beim Merge zu helfen. Und im Falle von gefundenen und korrigierten Fehlern spräche auch nichts dagegen, das wieder nach github zu bringen... Deswegen wollte ich mir Gedanken machen, bevor "das Kind in den Brunnen gefallen ist".

Ich werde mal am Wochenende weiter testen und über mein Ergebnis berichten.

Gruß, Waldemar

[Msinn]

Submodule beziehen sich immer auf einen festen Commit des sub-repos. Wenn Du eien git clone oder ein gitt pull auf das Hauptrepo machst, werden also nicht die neuesten Dateien des Subrepo gezogen. Nach jedem Commit im Subrepo müsste man das Hauptrepo aktualiseren, damit es auf das aktuelle subrepo zeigt. Das ist sinnvoll beim einbinden von Fremdsoftware, wo ich nicht automatisch/ungetestet die neue Version der Fremdsoftware nutzen will. Im shNG Context macht das nach meiner Meinung keinen Sinn.

[mumpf]

Ah, danke für die Info.

Für die Plugins von shNG macht das wirklich keinen Sinn. Und für das Autoblind-Plugin auch nicht wirklich. Allerdings könnte es aus der Sicht meines Haupt-Repos doch Sinn machen, denn da werden shNG und smartvisu zu zu dezidierten Zeitpunkten geholt (neue Releases) und sind so gesehen "Fremdsoftware".

Wie gesagt, ich werde am WE mal rumspielen, ich habe noch als Alternative zu Submodules noch über https://git-scm.com/book/de/v1/Git-T...ubtree-Merging gelesen, könnte auch passen und scheint einfacher zu verwalten zu sein. Erfahrungen habe ich keine (mit beiden Verfahren), aber man wächst ja mit seinen Aufgaben...

Gruß, Waldemar

[mumpf]

Wenn die Option angegeben ist, werten /etc, /logics und /items in diesem Verzeichnis abgelegt

Hi,

weiß jemand, ob das auch für /plugins und /scenes gilt? Ich habe nichts dazu gefunden außer bei der --help option, und da wird auch nur von /etc, /logics und /items gesprochen.

Bei /plugins würde ich mir sogar "wünschen", dass zuerst in dem durch die Option angegebenen Verzeichnis gesucht wird, und falls das Plugin da nicht gefunden wird, nochmal in dem Standard-Verzeichnis. So könnte man ein ausgeliefertes Plugin modifizieren ohne das per git pull geholte plugin anzufassen.

Wär so eine Anregung für die Zukunft...

Gruß, Waldemar

[Msinn]

• Bei Plugins: Nein, sie sind Teil des Codes und nicht der Konfiguration
• Bei Scenes: Muss ich nachsehen. Ich vermute: Nein, da derjenige der die Codeanpassung gemacht hat nichts mit Scenes am Hut hatte (glaube ich). Sollte aber einfach nachzuimplementieren sein.

[ratzi82]

Bei /plugins würde ich mir sogar "wünschen", dass zuerst in dem durch die Option angegebenen Verzeichnis gesucht wird, und falls das Plugin da nicht gefunden wird, nochmal in dem Standard-Verzeichnis.

Nur so als Tipp, mit docker ist das problemlos möglich, mache ich schon über 1 Jahr so. Dafür braucht es auch keinerlei Anpassungen in SmartHomeNG, kann ich nur empfehlen.
Genauso das Auslagern sämtlicher anderer Verzeichnisse geht mit docker, weil dem docker Container Verzeichnisse "reingemountet" werden können. Deswegen ging das auch schon vor der Anpassung die vor ein paar Monaten für /etc, /logics und /items gemacht wurde.

Gruß,
Henning

[mumpf]

Danke Henning,

wieder was gelernt. Ich habe mich mit docker (leider) noch nicht beschäftigt, mal schauen wann ich dazu komme.
Wenn mein git-Ansatz so läuft, wie ich mir das vorstelle, dann brauche ich ja gar keine dezidierten Verzeichnisse für Enduser, denn nach einem Merge sehe ich genau die Dateien, die von beiden Seiten geändert wurden (und bekomme eine relativ gute Hilfe, wie man das auflösen kann). Aber da ich zur Zeit sowieso verschiedene Herangehensweisen teste, ist Dein Tipp super.

Gruß, Waldemar