Zukunft von subversion?

[betateilchen]

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?

[rudolfkoenig]

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.

[Otto123]

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?

- Umstellung der ssh Zugaenge

Ist das dann überhaupt noch relevant? Da muss sich ja dann jeder Entwickler selbst mit git darum kümmern?

- 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.

[rudolfkoenig]

Wir 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.

Ist 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.

[Otto123]

Eine 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.

[rudolfkoenig]

Ich 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).