[Antwort] SVN Mirror auf Github

[dev0]

Einigen wird es vielleicht schon aufgefallen sein:
https://github.com/fhem/fhem-mirror/


Der SVN Mirror dort wird täglich automatisch per Travis CI aktualisiert. Dabei werden auch die Namen der Modulautoren auf Github Accounts umgeschrieben. Dafür müssen diese natürlich bekannt sein. Einige habe ich bereits eingetragen. Wenn jemand Wert darauf legt, dass seine SVN Commits auf Github auch seinem dortigen Account zugeordnet wird, der kann einen entsprechenden Pull Request stellen wie in der README.md im Branch "travis" beschrieben.

Davon abgeshen, dass ich meine, dass der fhem/FHEM Account auf Github dem FHEM Verein gehören sollte bzw. vom Verein gemanged werden sollte... frage ich mich welchen Sinn das ganze hat. Pull Requests fließen nicht ins svn, wozu dann das ganze?

Diese Diskussion möchte ich hier gar nich aufmachen. Ich wollte hier nur proaktiv Informationen verteilen, nichts weiter.

Ich habe Rudi als Mitglied für den Namespace eingeladen, die Einladung wurde aber nicht angenommen. Auch sonst hat Rudi keinerlei Avancen gezeigt sich überhaupt für das Thema Git oder auch Github zu begeistern. Wie gesagt, diese Diskussion möchte ich hier nicht führen, denn sie führt zu nichts.

Da Du den Thread, nach der ersten Antwort, geschlossen hast... Hier die Diskussion zu SVN Mirror auf Github

Wenn Du keine Diskussion aufmachen möchtest, dann schreib in diesem Forum keinen Breitrag dazu.
Wenn es weitere Meinungen dazu gibt, dann kann dieser Thread gerne dazu genutzt werden...
Meine Meinung habe ich bereits geäußert.

[betateilchen]

ich geh mal Popcorn holen...

Und danach suche ich vielleicht mal die Threads hier im Development raus, in denen es in der Vergangenheit bereits um das Thema "git" ging. Aber wirklich nur vielleicht.

[Loredo]

Ich werde mich nicht daran beteiligen. Wenn es konstruktiv wird, ruft mich.


Edit:
Nur eine Anmerkung steuere ich noch bei: Es gibt auf Github auch bereits andere Mirrors des SVNs, die aber weder offiziellen Charakter haben und auch nicht regelmäßig aktualisiert werden. Auch ist dort die SVN>Git Migration nicht so sauber. Eine Anfrage den existierenden Mirror umzuziehen wurde nicht beantwortet. Grund für den Mirror ist also lediglich hier eine Alternative unter dem /fhem Namespace anzubieten, die auch täglich aktuell ist. Einen Mirror generell zu haben: "Because we can" und "why not?". Niemand braucht ihn beachten, wenn er nicht will. Klare Hinweise über die Intention gibt auch das README.md.


Das Thema FHEM Namespace ist eine ganz andere Diskussion und die will ich hier nicht in provokativer Form geführt wissen. So wie dev0 das angefangen hat, geht das bei mir auch nach >/dev/null - Punkt.

[betateilchen]

Subversion kann man auch lokal aus dem Dateisystem betreiben, dass es nicht ueblich ist, ist eine andere Sache. Es geht mir gar nicht um die git vs. subversion Diskussion (sourceforge bietet git an), sondern um die sourceforge vs. github vs. andere Alternative. Mit github habe ich die gleichen Probleme, wie mit sourceforge (und vorher Berlios): wenn der Besitzer meint, es geht auch mit weniger Betreuung oder Hardware, damit der Shareholder- Value steigt, dann hat man keinen Einfluss darauf, ausser weiterzuziehen.
Ich bin z.Zt. auf der Suche nach der "anderen Alternative", und nein, ich brauche dafuer keine Hilfe, sondern Zeit.

Offenbar haben die knapp 4 Jahre Zeit seit diesem Beitrag nicht ausgereicht, eine Alternative zu finden und zu etablieren.


Und solange dieses für mich absolut nicht nachvollziehbare Totschlagargument

Inzwischen habe ich Erfahrung mit git sammeln duerfen, und ich bin dankbar, dass ich es in wenigstens in FHEM nicht verwenden muss: mAn bietet git Features, die bei FHEM nicht benoetigt werden, und ist selten unlogisch in der Benutzung.

im Raum steht, erübrigt sich doch ohnehin jede weitere Diskussion.

[Beta-User]

Offenbar haben die knapp 4 Jahre Zeit seit diesem Beitrag nicht ausgereicht, eine Alternative zu finden und zu etablieren.

Ging es bei dem Zitat nicht um die Frage, auf welchen Server das Repo zu finden ist?

Nach meinen Kenntnisstand ist das jetzt ein Server, den der eV. betreibt. Ist das nicht genau die Änderung, die da vor Jahren mal angestrebt war?

Ansonsten empfinde ich als "Gelegenheitsnutzer" svn als weniger zickig als git, aber ohne damit behaupten zu wollen, das eine oder andere überhaupt "richtig" zu kennen und daher irgendeine qualifizierte Aussage dazu machen zu können.

[zap]

Ich denke, solange jeder Entwickler sein Modul pflegt und keine Pull Request o.ä. Benötigt werden, ist SVN ok. Für reines Ein-/Auschecken reicht es.
Ist halt ein angestaubtes Relikt aus dem IT Paläozän (ich glaube, nur COBOL ist älter). Aber so what. 

[betateilchen]

Ging es bei dem Zitat nicht um die Frage, auf welchen Server das Repo zu finden ist?

Das war der eine Teil, ja. Aber da steht auch, dass es eigentlich nicht um die Frage "git vs. svn" geht.
Zu diesem Zeitpunkt wäre vermutlich noch ein Wechsel zu git auf einer (alternativen) Plattform denkbar gewesen.

Nach dem Zitat aus September 2018 scheint das aber nun überhaupt keine Option mehr zu sein.

[igami]

Ich fände es gut, wenn in dem fhem namespace auch die ganzen inoffiziellen Module verlinkt werden, die ausschließlich per github verfügbar sind (FTUI, Abfall, ...).

[Christoph Morrison]

Niemand braucht ihn beachten, wenn er nicht will. Klare Hinweise über die Intention gibt auch das README.md.

Und trotzdem ein Danke für die Infrastruktur. Ich arbeite z.B. nur auf einem Git-Mirror von FHEM und freue mich, wenn es einen sauber aufgesetzten gibt.

[Loredo]

Ich fände es gut, wenn in dem fhem namespace auch die ganzen inoffiziellen Module verlinkt werden, die ausschließlich per github verfügbar sind (FTUI, Abfall, ...).

In der Tat. Ich habe mühsam versucht eine Liste aller externen Repos zusammenzusuchen, damit ich prüfen kann, welche externen Abhängigkeiten ein Modul hat (für das Docker Image). Die Liste liegt derzeit mit im Docker Repo: https://github.com/fhem/fhem-docker/blob/dev/src/unofficial_controls.txt
Dieses Script geht dann alle Repos durch und prüft dann wiederum mit anderen Scripts mögliche Abhängigkeiten.


André hatte ich schon angeboten die Node.js Sourcecodes umziehen und selbstverständlich hätte André auch alle Rechte von mir delegiert bekommen, auch für den Namespace an sich.

Dass sich so viele Projekte inzwischen nicht in das SVN einchecken dürfte durchaus zeigen, dass Git vielerorts bevorzugt wird. Oder eben ein separates Repo. Beides kann Github bieten (natürlich auch Gitlab o.ä.). Der Vereinsserver ist dafür doch sehr beschränkt. Und ehrlich: Wer will sich als Entwickler denn mit dem Betrieb von Servern beschäftigen (Features, Updates, Security, etc) statt sich auf die eigentliche Kernaufgabe zu konzentrieren... just my two cents.
Ich mag auch gerne Patches als Pull requests bekommen, es erleichtert den Code Review doch enorm. Auch weiß ich es zu schätzen, dass Travis CI im Falle des Docker Images immer sofort ein neues Image zur Probe baut und auch einen Health-Check durchführt, ob das Image mit dieser Änderung noch korrekt läuft. Wer wollte denn einen solchen Build Server mit genug Power in der Vereins-Cloud aufsetzen und pflegen, abgesehen von den ganzen fehlenden Trigger-Integrationen mit anderen Tools.

Aber wie gesagt, diese Grundsatzdiskussion zu Git und der Nutzung von externen Cloud Diensten wollte ich nicht erneut entfachen, ich habe den Status Quo bisher so hingenommen. Mehr als zu versuchen Brücken zwischen beiden Seiten zu bauen, kann man da wohl nicht tun.

[dev0]

Dass sich so viele Projekte inzwischen nicht in das SVN einchecken dürfte durchaus zeigen, dass Git vielerorts bevorzugt wird.

Das es an svn/git liegt ist eine Möglichkeit das zu interpretieren. Ich habe zB. einige Projekte nicht ins FHEM svn eingecheckt, da ich keine Zeit und Lust habe diese Projekte auf Dauer zu betreuen und das contrib Verzeichnis leider nicht via Update aktualisert wird.

[justme1968]

Dass sich so viele Projekte inzwischen nicht in das SVN einchecken dürfte durchaus zeigen, dass Git vielerorts bevorzugt wird.

das muss man zumindest etwas differenzierter sehen. die node module sind nur deshalb bei git weil sie sich so am einfachsten per npm veröffentlichen lassen.

was die fhem module im svn angeht: ich bin bisher noch an keine einzige einschränkung gestossen, es gab keinen einzigen fall in dem jemand einen größeren patch geliefert hat oder aus irgend einem anderen grund git besser gewesen wäre. im gegenteil.

bei alexa-fhem ist es anfang des jahres mit georg tatsächlich das erste mal zu einer größeren zusammen arbeit gekommen. auch hier fand ich das git modell eher hinderlich.


die theoretischen vorteile von git/github sind zumindest in einer ganzen reihe von bereichen nicht so relevant wie die tatsächlichen vorteile von svn und einem eigenen repository.


aber all das ist doch kein grund zu streiten. wir sollten schauen das wir fhem voran bringen. eine solche brücke wird wenn sie gut funktioniert fakten schaffen. aber eben auch nur wenn es eine einzige gute brücke ist. und nicht x GitHub forks...

[nils_]

auch hier fand ich das git modell eher hinderlich.

was ist denn "das git modell" ??

die theoretischen vorteile von git/github sind zumindest in einer ganzen reihe von bereichen nicht so relevant wie die tatsächlichen vorteile von svn und einem eigenen repository.

man könnte ja auch..... https://git-scm.com/book/de/v1/Git-und-andere-Versionsverwaltungen-Git-und-Subversion

[Loredo]

man könnte ja auch..... https://git-scm.com/book/de/v1/Git-und-andere-Versionsverwaltungen-Git-und-Subversion

DAS ist dann wirklich Schmerz im Hinterteil


One-way funktioniert Git-SVN so einigermaßen, so wird ja der Mirror betrieben. Aber es fängt dann schon dabei an, dass SVN so ineffizient mit Branches umgeht und man leider jeden Branch einzeln mit auschecken muss und das bedeutet, dass jede Datei dann mehrfach geladen und auch verarbeitet werden muss. Daran habe ich mich mehrere Tage versucht, aber es irgendwann aufgegeben. Deshalb gibt es keine Tags beim Mirror. Aber da wir ja an anderer Stelle schon festgestellt haben, dass diese eigentlich auch nicht wirklich relevant sind für FHEM, war mir das irgendwann dann auch wirklich egal


Git-SVN ist jedenfalls nicht für einen dauerhaften Parallelbetrieb konzipiert, sondern ist als Migrationspfad gedacht. Und sowas haben wir nicht vor.

[nils_]

der vorschlag war auch nicht wirklich ernst gemeint....
ich wollte es ja nur mal erwähnt wissen