Moin,
in den letzten Tagen bin ich an immer mehr Stellen gescheitert, an denen mehr oder weniger "plötzlich" keine Unterstützung für svn mehr existiert.
- in den Apple Developer Tools ist schon länger kein subversion mehr enthalten, man muss auf Drittanbieter wie homebrew oder macports zurückgreifen
- mein bevorzugter (gekaufter!) code-Editor BBedit hat vor vier Tagen die Version 16 veröffentlicht. Dann habe ich erfolglos die svn-Integration des Editor gesucht, die plötzlich nicht mehr sichtbar war.
Also doch mal einen Blick in die vollständigen Release Notes geworfen. Ganz lapidar steht da "Subversion support has been retired." Da bin ich nun wieder auf die vorherige Version 15.5 zurückgegangen und habe mir das Installationsimage gut weggespeichert. - Der Hersteller meines vor einigen Jahren gekauften svn-GUI-client Xversion bietet auf der ziemlich verwaisten Webseite keinen brauchbaren Download mehr an. Die App ist zwar im Apple App-Store noch gelistet, aber da kann ich sie offenbar nur nochmal neu kaufen. Ob das dann wirklich funktioniert? Keine Ahnung. Und ich würde ja gerne meine existierende Lizenz weiterverwenden.
Bei all diesen Erlebnissen frage ich mich langsam ernsthaft, wo die Zukunft von subversion liegt und wie sie sich entwickeln wird?
Ich sehe auch, dass SVN den Weg von CVS geht, und habe gegen einen Umstieg auf git nur die damit verbundenen Aufwaende einzuwenden:
- Migrieren der SVN Versionen nach git
- Migrieren der SVN Hooks
- Umstellung der ssh Zugaenge
- Trac Alternative suchen (existierende Links gehen verloren oder wir behalten trac im Archivmodus?)
- Anpassen von fhemupdate (Serverseite von updatefhem)
- jeder Entwickler muss den Code neu auschecken, und lokale, nicht eingecheckte Versionen uebertragen.
Das "Web" behauptet: SVN ist nach wie vor relevant und ein sichere und stabile Plattform. Ist es eher so, dass sämtliche Tools sich davon abwenden?
Wir bräuchten keinen eigene SVN Server mehr und allen Aufwand und Probleme, die wir damit haben, sind "delegiert" an git. Es gibt offenbar eine Reihe Migrationstools, "man" sollte sich mal damit beschäftigen? ;)
Zitat von: rudolfkoenig am 26 Mai 2026, 10:47:34- Umstellung der ssh Zugaenge
Ist das dann überhaupt noch relevant? Da muss sich ja dann jeder Entwickler selbst mit git darum kümmern?
Zitat von: rudolfkoenig am 26 Mai 2026, 10:47:34- Trac Alternative
gibt wohl ein Plugin für git, d.h. man könnte trac behalten. Allerdings nutzt dies wohl keiner mehr, da auch hier die Funktionen in git moderner abgebildet sind. Ich kann die Bedeutung gar nicht richtig einschätzen.
ZitatWir bräuchten keinen eigene SVN Server mehr...
Eine zentrale Stelle muss es aber doch geben, auch wenn die komplette Historie bei jedem Entwickler lokal vorhanden ist.
ZitatIst das dann überhaupt noch relevant? Da muss sich ja dann jeder Entwickler selbst mit git darum kümmern?
Ein Entwicklerzugang per SSH fuehrt z.Zt. svnserve aus, damit ist git vmtl. nicht gluecklich.
Siehe /etc/ssh/authorized_users/fhem/* @ fhem2-svn, diese 152 Dateien muessen wir passend aendern.
Was ich vergessen habe, und bei git echt nerwig ist: fortlaufende Versionsnummer gibt es nicht, nur Ellenlange commit-ids.
Ich habe es noch nicht geschafft sowas mit git sauber nachzubauen.
Zitat von: rudolfkoenig am 26 Mai 2026, 13:25:22Eine zentrale Stelle muss es aber doch geben
Ich dachte, man nutzt einfach github.com,
- legt einen Vereinsaccount an (gibt es eventuell schon ...?),
- legt ein Repository an und
- berechtigt über Settings/Collaborators/Manage Access
?
Bedeutet: jeder Entwickler braucht einen github Account. Wir haben mit der ganzen Sache nichts weiter zu tun, außer auf Zuruf die Collaborators zu berechtigen. Ist das ein falscher / unschöner Gedanke? Ich verstehe von dem Ganzen eventuell zu wenig.
Wenn die Microsoft KI unseren Code 10 mal in der Stunde lesen will, tun sie das dann auf ihrem Server und belasten unseren nicht. ;)
ZitatIch dachte, man nutzt einfach github.com,
Nicht mit mir.
Ich will nicht bei sowas von Anderen abhaengen, das habe ich schon mit FHEM zweimal hinter mir (berlios und sourceforge).
Ich verwende privat das absolute pflegeleichte GOGS (https://gogs.io).
Sieht aus wie github, fühlt sich wie github an, und funktioniert für meine bescheidenen Ansprüche wie github.
Zitat von: rudolfkoenig am 26 Mai 2026, 16:48:47Nicht mit mir.
ok verstanden, dann war ich falsch abgebogen. ;)
Man kann ja mal in der Hetzner Cloud eine kleine Infrastruktur aufbauen zum rumspielen.
Wir wollten auch Containerisieren, das kann man testen.
Ich werfe mal gitea und Forgejo als Git Server in die Runde. Gitlab wäre da wohl etwas zu Groß denke ich.
Zitat von: rudolfkoenig am 26 Mai 2026, 13:25:22Was ich vergessen habe, und bei git echt nerwig ist: fortlaufende Versionsnummer gibt es nicht, nur Ellenlange commit-ids.
Ich habe es noch nicht geschafft sowas mit git sauber nachzubauen.
Moin,
Was ist die Anforderung die hinter fortlaufend steht?
Vielleicht wäre dafür folgendes eine Alternative:
Man markiert einen Release-Stand mit einem Tag wie v6.4.0, und kann danach mit git describe etwas wie v6.4.0-3-gabc1234 bekommen, also ,,3 Commits nach Tag X".
Sie SHA256 Quersumme bekommt man bei Wunsch auch noch von der Ausgabe entfernt.
Alternativ setzt man eine Pipeline auf, die bei jedem commit ein Tag setzt und dies hochzählen lässt.
Ob das jetzt nach semVer Schema oder einfach ein counter ist, kann ausgestaltet werden.
Grüße Sidey
Ich habe aktuell einiges an IaC ausgearbeitet. Aktuell mittels Terraform und Proxmox. Damals gab es für den Hetzner Client ein Terraform Provider, gibt sowas bestimmt immer noch. Muss ich mal schauen.
Damit kann man binnen Minuten Server ausrollen und dann mittels Ansible die Konfig betanken.
Beispiel:
Ich rolle 5 VMs auf Proxmox aus mittels Terraform und bespiele eine Grundkonfiguration mit User und SSH Pubkey. Danach wird ein Kubernetes Cluster mit 3 Controlplan Nodes und 2 Worker Nodes auf den VMs angelegt.
Das ganze dauert keine 5 Minuten inklusive Calico Netzwerk Plugin über Tigera Operator.
Rudi wenn Du das Go gibst und wir bisschen Geld in der Kasse haben kann ich da bei Gelegenheit mal rumspielen.
Am Ende der Spielerei sollte ein Kubernetes Cluster stehen für Gitea und zum testen von Forum deployen mittels Container und hat was sonst noch so gewünscht ist.
Erlaubt Gitea die bisherigen ssh-Schluessel zu uebernehmen?
Wenn nicht, wie regelt man den Zugang?
Jeder Entwickler bekommt ein Konto wo er sich anmelden kann. Da kann er dann auch SSH schlüssel hinterlegen. Über den ssh Schlüssel kann er dann in seine ihm zugeordneten Repositorys schreiben, oder halt nur lesen. Das Prinzip ist ein bisschen anders wie bei SVN denke ich.
Gitea ist im Grunde wie GitHub.
ZitatJeder Entwickler bekommt ein Konto wo er sich anmelden kann.
Mir faellt dazu nur ein, 150 Benutzer anzulegen, deren Emailadresse aus dem Forum rauszusuchen, und eine email mit dem Passwort zu senden.
Leider entspricht der SVN-Benutzername nicht immer dem Namen im Forum.
Ich hoffe es gibt einen besseren Weg.
Es gibt da diverse Wege. Man kann unterschiedliche Identity Provider benutzen. Auch möglich wäre Selbstregistrierung da muss man dann mal schauen was sich als praxistauglich erweist.
Ich kann und möchte Kubernetes nicht supporten/administrieren.
Proxmox und Docker ist kein Problem - bei dem was Cooltux jetzt erklärt stehen bei mir nur Fragezeichen. Am Ende ist keiner da, der diese Plattform am Leben hält.
Klingt für mich nicht nach Migration sondern nach Neuanfang.
ZitatAm Ende ist keiner da, der diese Plattform am Leben hält.
Danke, das Du es auf den Punkt bringst...
Zitat von: rudolfkoenig am 28 Mai 2026, 21:06:13Mir faellt dazu nur ein, 150 Benutzer anzulegen, deren Emailadresse aus dem Forum rauszusuchen, und eine email mit dem Passwort zu senden.
Leider entspricht der SVN-Benutzername nicht immer dem Namen im Forum.
Ich hoffe es gibt einen besseren Weg.
Jeder Maintainer benötigt heute einen Forums Account.
Zum Account gibt es eine E-Mail-Adresse.
Neue User müssen sich registrieren.
Idealerweise nutzt man für das Forum und dem Git Service die gleichen IDP. Dann läuft es nicht auseinander.
Grüße Sidey
Zitat von: Otto123 am 28 Mai 2026, 22:24:40Ich kann und möchte Kubernetes nicht supporten/administrieren.
Proxmox und Docker ist kein Problem - bei dem was Cooltux jetzt erklärt stehen bei mir nur Fragezeichen. Am Ende ist keiner da, der diese Plattform am Leben hält.
Klingt für mich nicht nach Migration sondern nach Neuanfang.
Selbstverständlich geht auch Docker. Im Zuge dessen kann man aber auch mal schauen das man das ganze aufsetzen und konfigurieren automatisiert.
Wenn man die gesamte FHEM e.V. Umgebung neu machen müsste bräuchte man doch locker einen bis anderthalb Tage. Mit Automatisierung hast Du alles in einer halben Stunde stehen, komplett mit 100 Prozent Konfiguration genau so wie sie heute steht.
Nur als Beispiel.
Bevor wir alles automatisch neu machen ging es hier erstmal um SVN und einen möglichen Ersatz. Ich fasse mal die Vorschläge zusammen:
Zu klären / testen / entwickeln ist:
- Userverwaltung
- FHEM Update
- Migration des jetzigen Entwicklungsstandes
- Bildung Versionsnummern
- Beibehaltung / Alternativen zu jetzigen SVN Features wie trac, SVN Hooks
Ursprüngliche Frage von betateilchen war aber die Unterstützung von vorhandenen Entwicklertools, Editoren, Plugins usw. Ist da das backend "egal" und reicht dafür "ist wie github" - ich denke die fokussieren sich alle auf github - oder sehe ich das falsch?
Die "Containerisierung" und Automatisierung der Infrastruktur sollten wir getrennt diskutieren, da habe ich mich auch ziemlich viel damit beschäftigt (allerdings nicht unter dem Begriff IaC ;) ).
GitHub ist im Grunde Git. Egal welchen Gitserver man nimmt. Gitea, GitHub oder Gitlab. Das Prinzip ist bei allen gleich. Nur die Extras dann halt mal mehr mal weniger. Pipelines und sowas. Migration soll wohl mittels commandline tool auch ganz einfach sein. svn-git oder sowas. Ich schicke Dir mal einen Link.
User-Verwaltung und vor allem wie man mit Git arbeitet wird dann schon interessanter. Die Art und Weise wie man mit Git als Team oder Contributor arbeitet ist total anders zu SVN.
Zitat von: Otto123 am 29 Mai 2026, 09:54:39Zu klären / testen / entwickeln ist:
- ...
- FHEM Modul "fheminfo"
- FHEM Modul "version"
- Die komplette FHEM Statistik
- ...
Zitat von: Otto123 am 29 Mai 2026, 09:54:39Ursprüngliche Frage von betateilchen war aber die Unterstützung von vorhandenen Entwicklertools, Editoren, Plugins usw.
Inzwischen habe ich die bisher benutzten Tools auch auf dem neuen macBook wieder in Betrieb, eben in den vorherigen Versionen, die auch noch subversion unterstützen. Auf die Installation von updates dieser Tools werde ich einfach verzichten. Für meine Zwecke sind sie alle gut und ausgereift, so wie sie jetzt sind.
Insofern kann ich auch noch ein paar Jahre weiter mit svn leben.
Der Thread hatte nicht den Zweck, jetzt kurzfristig eine Umstellung bei FHEM anzustreben, sondern einfach eine Diskussion und anzustoßen und zu erfahren, ob andere Entwickler ähnliche Erfahrungen gemacht haben.
Alle großen Smarthome Plattformen (ioBroker, Homeassistant, OpenHab) nutzen Github. ioBroker pflegt Listen von Repos. Selbst das ist eigentlich zuviel Aufwand.
Natürlich kann man sich auch die Mühe machen, selbst einen Git-Server zu betreiben. Aber warum?
Man könnte höchstens einen Mirror aufsetzen (als Backup).
Ich entwickle schon seit Jahren nur noch mit Github. Habe mir ein paar Scripts gebaut, die hin und wieder etwas von Git ins SVN-Repo übernehmen. Aber man kann natürlich auch einfach ein FHEM Modul direkt aus Github über die URL installieren.