Autor Thema: [Umfrage] künftige Versionsverwaltung für fhem  (Gelesen 10243 mal)

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
[Umfrage] künftige Versionsverwaltung für fhem
« am: 17 Februar 2014, 20:55:42 »
Edit - 12.02.2015 - inzwischen kam hier im Thread die Frage nach der künftig bevorzugten Versionsverwaltung auf.

Bitte runterscrollen oder klicken http://forum.fhem.de/index.php/topic,20395.msg260898.html#msg260898 :)



Mit meiner Client Software (Versions 1.3.0) bekomme ich heute regelmäßig Error 500 beim Commit ins SVN.
Von der OS-Konsole per svn commit funktioniert alles wie üblich.

Gab es irgendwelche Änderungen?
« Letzte Änderung: 12 Februar 2015, 22:27:09 von betateilchen »
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Online herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4702
Antw:Hat sich bei SVN irgendwas geändert?
« Antwort #1 am: 17 Februar 2014, 21:01:45 »
Macht auch über das Web Probleme. Slow und 500 internal server...

vg
Jörg
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19536
Antw:Hat sich bei SVN irgendwas geändert?
« Antwort #2 am: 17 Februar 2014, 21:08:10 »
Ich habe nichts geaendert. Sourceforge at its best. Seufz.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:Hat sich bei SVN irgendwas geändert?
« Antwort #3 am: 17 Februar 2014, 21:51:22 »
zumindest bin ich beruhigt, dass ich nicht alleine mit dem Problem bin :)
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:Hat sich bei SVN irgendwas geändert?
« Antwort #4 am: 15 Dezember 2014, 19:02:56 »
gibts heute wieder irgendwelche Probleme mit SVN?
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19536
Antw:Hat sich bei SVN irgendwas geändert?
« Antwort #5 am: 15 Dezember 2014, 19:06:27 »
Ja:
Zitat
Transmitting file data .svn: E000030: Commit failed (details follow):
svn: E000030: Can't open file '/svn/p/fhem/code/db/txn-current-lock': Read-only file system

Offline immi

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 915
Antw:Hat sich bei SVN irgendwas geändert?
« Antwort #6 am: 15 Dezember 2014, 21:14:41 »
same problem
svn commit -m "00_THZ.pm: improvement in communication for slow interfaces"
Sending        fhem/FHEM/00_THZ.pm
Transmitting file data .svn: E000030: Commit failed (details follow):
svn: E000030: Can't open file '/svn/p/fhem/code/db/txn-current-lock': Read-only file system

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:Hat sich bei SVN irgendwas geändert?
« Antwort #7 am: 15 Dezember 2014, 21:24:31 »
ok, danke. Dann muss ich mir keine Gedanken machen :)

ERROR from SVN:
RA layer request failed: Server sent unexpected return value (500 Internal Server Error) in response to POST request for '/p/fhem/code/!svn/me'
W: 9c8dafaaf3ec329cf12327b0ee9448521340cf89 and refs/remotes/trunk differ, using rebase:
:040000 040000 5ea392262c43664858633261af61d1c82cee22ce fcaddd2f6f9379353efd2791357df050851fa1e4 M fhem
ERROR: Not all changes have been committed into SVN, however the committed
ones (if any) seem to be successfully integrated into the working tree.
Please see the above messages for details.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:Hat sich bei SVN irgendwas geändert?
« Antwort #8 am: 10 Februar 2015, 21:22:54 »
irgendwie klemmts heute wieder...

ERROR from SVN:
RA layer request failed: Server sent unexpected return value (500 Internal Server Error) in response to POST request for ...
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4317
    • tech_LogBuch
Antw:Hat sich bei SVN irgendwas geändert?
« Antwort #9 am: 12 Februar 2015, 20:59:54 »
ich konnte vorgestern auch nichts einchecken...

(git haben wollen ;) )
In Verwendung: HM, EnOcean, 1wire, Firmata, MySensors, ESPEasy, MQTT*, NodeRED, Alexa, Telegram,..
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy
Kaffeekasse: https://www.paypal.me/s6z

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:Hat sich bei SVN irgendwas geändert?
« Antwort #10 am: 12 Februar 2015, 21:02:48 »
(git haben wollen)

*unterschreib*

Mach doch mal eine Umfrage, aber vergiss das Toastbrot nicht.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4317
    • tech_LogBuch
Antw:Hat sich bei SVN irgendwas geändert?
« Antwort #11 am: 12 Februar 2015, 21:09:31 »
Bitt'schön!  ;D
*duck*
In Verwendung: HM, EnOcean, 1wire, Firmata, MySensors, ESPEasy, MQTT*, NodeRED, Alexa, Telegram,..
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy
Kaffeekasse: https://www.paypal.me/s6z

Offline Markus Bloch

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 3501
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #12 am: 13 Februar 2015, 16:55:13 »
ich würde mich sowieso freuen, wenn FHEM von Sourceforge weggeht, da wir bis auf das SVN keine weiteren Features von Sourceforge nutzen (Tickets, Release-Downloads, usw.). Toll wär ein SVN Server direkt unter fhem.de , da weis ich aber nicht, ob das ressourcentechnisch möglich ist.

git habe ich bisher nicht genutzt, bin ich aber nicht gegen abgeneigt.

PS: dass das Toastbrot alle ist, finde ich sehr schade, dabei mag ich doch so gerne Toastbrot ;-)
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #13 am: 13 Februar 2015, 17:09:56 »
Toll wär ein SVN Server direkt unter fhem.de , da weis ich aber nicht, ob das ressourcentechnisch möglich ist.

Wenn schon was Neues/Eigenes aufsetzen, dann aber doch bitte nicht mehr SVN.
An den Ressourcen soll es nicht scheitern, da kann ich helfen.


-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline Markus Bloch

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 3501
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #14 am: 20 Februar 2015, 15:53:54 »
juhu, SF ist wieder mal down.....

@Rudi: was meinst du denn so generell zu dem Thema?
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19536
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #15 am: 20 Februar 2015, 20:15:39 »
Das waere der zweite Umzug (zuletzt vom berlios nach sourceforge), und ich habe behalten, dass es ein Haufen Arbeit ist (jedenfalls was mich betrifft), mit wenig Netto-Gewinn.

- man muss einen besseren Server als Sourceforge besorgen. Wobei besser subjektiv ist: ich wuerde einen Standort in Deutschland bevorzugen, und ein Rechenzentrum, damit man nicht auf die Anwesenheit von einem Privatperson beim Hardwareproblemen angewiesen ist.
- auf dem Rechner muss eine Benutzerverwaltung fuer diesen Zweck installiert sein, also Userpflege+GIT aber kein echter Zugang.
- die Entwickler muessen sich alle neu anmelden, d.h. man muss 40-50 Leute neu berechtigen.
- Quellen ruebertragen (ich will die alten Versionen nicht verlieren)
- fhemupdate + meine lokale Sicherung der Quellen anpassen
- mich in Git + Git-Hooks einarbeiten, Hooks erstellen.
- fhem-doku anpassen.
- FHEM@sourceforge zumachen.
- alle Entwickler muessen die Quellen neu auschecken, und darauf achten, dass lokale Aenderungen nicht verloren gehen.
- Uebrigbleiben etliche tote Links im fhemwiki/Blogs/etc.

Auf der Haben Seite sollte eine stabilere Verbindung stehen, d.h. man kann dann einchecken, wenn man will.

-> Im Moment wuerde ich das Problem eher aussitzen, es sei denn sourceforge kriegt es nicht hin.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #16 am: 21 Februar 2015, 10:03:21 »
Zumindest die ersten vier Punkte Deiner Liste habe ich bereits länger umgesetzt :) Bei mir läuft ein git repository, in dem ich auch alle Benutzer, die hier in "SVN Schreibberechtigung" aufgelistet werden, auch als git-User mit Certificate-Authentication vorhanden sind.

-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline Wuppi68

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1783
  • Wuppertaler Wimpelbeauftragter
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #17 am: 21 Februar 2015, 11:11:09 »
wenn man wechselt, kann man dann nicht einen smoothen Übergang machen?

Neues System spiegelt erst einmal die SourceForge Version sodass es mit beiden funktioniert? Und danach SF auf ReadOnly umstellen und irgendwann abschalten?

Was ist den an Traffic von uns auf dem SF Server?
Jetzt auf nem I3 und primär Homematic

kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #18 am: 21 Februar 2015, 14:45:42 »
- die Entwickler muessen sich alle neu anmelden, d.h. man muss 40-50 Leute neu berechtigen.

Die Entwickler müssen sich nicht neu anmelden, sie bekommen lediglich neue Zugangsdaten, das lässt sich weitgehend automatisieren (verbunden mit einem gleichzeitigen Check, ob die registrierten email-Adressen noch aktuell sind)

Ein eben ausgeführter Migrationstest hat ergeben, dass  das nicht 40-50 Personen wären, sondern 109 - nämlich alle User, die bisher jemals in svn eingecheckt haben. Die müssen auch dem migrierten git bekanntgemacht werden.


wenn man wechselt, kann man dann nicht einen smoothen Übergang machen?

Eine Migration von svn zu git läuft normalerweise so ab, dass in der Migrationsphase alle Entwickler weiterhin nach svn einchecken und das svn dann nach git als read-only gespiegelt wird. Irgendwann kommt dann der Zeitpunkt des Umschaltens. Ab diesem Moment wird svn gesperrt und git freigegeben, danach wird nur noch in git eingecheckt.

-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #19 am: 21 Februar 2015, 17:36:24 »
Das waere der zweite Umzug (zuletzt vom berlios nach sourceforge), und ich habe behalten, dass es ein Haufen Arbeit ist (jedenfalls was mich betrifft),

Nirgends steht geschrieben, dass Du einen solchen Umzug alleine stemmen musst. Falls Du eine Migration irgendwann doch ins Auge fassen solltest, melde Dich einfach. Die meisten der von Dir oben beschriebenen Aufgaben sind bereits erledigt und müssen nur noch scharfgeschaltet werden.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #20 am: 23 Februar 2015, 22:39:05 »
Heute ist meine Testmigration auf einen eigenen Server im Rechenzentrum umgezogen. Wer gerne mal git "fühlen" möchte, kann unter der Adresse git://fhem.betateilchen.de/fhem_ro.git auf das fhem-Repository per git zugreifen.

Achtung: Der Zugriff ist read-only!

Es sollten alle fhem releases seit 4.0 zu finden sein - mehr ist offenbar auch in svn nicht vorhanden. Die Synchronisation zu fhem-SVN sollte mit einer maximalen Verzögerung von fünf Minuten stattfinden.

« Letzte Änderung: 02 März 2015, 21:47:19 von betateilchen »
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #21 am: 26 Februar 2015, 22:01:33 »
Hallo Rudi,

- mich in Git + Git-Hooks einarbeiten, Hooks erstellen.

Der pre-receive hook für git, der die commit-Message und die commandref prüft, funktioniert inzwischen auch 8)

Allerdings habe ich dazu noch eine Frage:


      if($l =~ m/^=begin html$suffix$/) {
        $l = <MOD>;    # skip one line, to be able to repeat join+split
        err($fName, "$lang: nonempty line after =begin html.")
          if($l =~ m/^...*$/);
        $skip = 0; $line++;


Das bekomme ich im hook noch nicht abgebildet, weil ich nicht direkt aus der Datei lesen kann, sondern aus dem im commit geschickten content. Also arbeite ich mit foreach() ein Array ab und innerhalb dieser Schleife kann ich natürlich nicht einfach eine weitere Zeile lesen.

Wieso ist das Fehlen der Leerzeile nach =begin_html ein Fehler?


Hast Du noch weitere hooks in SVN im Einsatz? In ./contrib habe ich nichts gefunden - oder ich habs übersehen.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19536
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #22 am: 27 Februar 2015, 09:53:46 »
Die Leerzeile ist aus historischen Gruenden da: Doku in den Modulen ist erst 3 Jahre alt, davor musste jeder commandref.html modifizieren. Als es absehbar war, dass es so nicht weitergeht, habe ich commandref_split & join gebaut. Da ich unsicher war, ob split/join richtig funktioniert, wollte ich sicherstellen, dass nach split+join die Doku mit dem alten identisch ist. Ich meine mich daran zu erinnern, dass split immer ein Leerzeichen einfuegt, und falls im Input das nicht vorhanden ist, dann meldet ein anschliessend gemachter diff Unterschiede.
Vermutlich kann man die Pruefung entfernen.

Ich habe z.Zt. nur diesen Hook im Einsatz.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #23 am: 27 Februar 2015, 10:12:19 »
Danke für die Info.

-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #24 am: 27 Februar 2015, 18:41:27 »
Für alle Statistik-Freaks:

https://fhem.betateilchen.de/statistics.html

https://fhem.betateilchen.de/gitstat

(Aktueller Stand, täglich aktualisiert, Auswertungszeitraum ab 01.01.2015)
« Letzte Änderung: 02 März 2015, 21:46:43 von betateilchen »
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19536
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #25 am: 27 Februar 2015, 19:44:12 »
Ich weiss nicht, ob ich das auch als Statistik bezeichnen wuerde:

Zitat
Not Found
The requested URL /statistics.html was not found on this server.
Apache/2.2.22 (Debian) Server at fhem.betateilchen.de Port 443

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #26 am: 27 Februar 2015, 19:58:51 »
Wir sind ja schließlich nicht auf einer Berliner Flughafenbaustelle  8) Auf meiner Baustelle hier wird jedenfalls auch am Freitagabend fleißig gearbeitet, damit was fertig wird. So ungefähr sollte das Ergebnis aussehen:

(http://up.picr.de/21129472by.jpg)
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19536
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #27 am: 27 Februar 2015, 23:26:15 »
Jetzt musst du nur noch erklaeren, wie du die Statistiken berechnet hast.
Ich kaufe es dir naemlich nicht ab, dass Du doppelt so viel an FHEM geaendert hast, wie ich. :)

http://en.wikipedia.org/wiki/Lies,_damned_lies,_and_statistics :
'There are three kinds of lies: lies, damned lies, and statistics.'

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #28 am: 27 Februar 2015, 23:43:39 »
Das steht doch in den Spaltenüberschriften? commits, insertions und deletions.

Ich kaufe es dir naemlich nicht ab, dass Du doppelt so viel an FHEM geaendert hast, wie ich. :)

Wie ich weiter oben bereits geschrieben hatte, ist der Betrachtungszeitraum der Statistik das laufende Jahr 2015. Und in den vergangenen zwei Monaten habe ich definitiv mehr eingecheckt als Du, denn Jan/Feb war die Geburt von 55_InfoPanel und 98_help - da sind die 3471 Zeilen code durchaus realistisch, das InfoPanel alleine hat aktuell knapp 2000 Zeilen.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline Markus Bloch

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 3501
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #29 am: 28 Februar 2015, 08:21:42 »
Ich war auch erst verdutzt, aber wenn man vom 01. Januar ausgeht, dann kommt das bei mir schon hin. Hab nur wenige Sachen seit dem eingecheckt.
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #30 am: 28 Februar 2015, 11:40:28 »
Der Betrachtungszeitraum und das Erstellungsdatum der Liste stehen jetzt auch ganz oben auf der Seite.

Aus Performancegründen - um die Statistik überhaupt zu testen - habe ich den Zeitraum einfach aktuell noch begrenzt. Natürlich kann man die Auswertung auch über die gesamte fhem-Zeitrechnung laufen lassen.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #31 am: 28 Februar 2015, 16:42:53 »
Ich bräuchte mal bitte 3-5 Anwender, die mich als Testuser bei der Einrichtung eines git-Servers unterstützen. Vor allem, um evtl. auf Anwenderseite auftretende Schwierigkeiten in einer entsprechenden Doku berücksichtigen zu können.

Wer Interesse hat, meldet sich bitte per email bei mir.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline Markus Bloch

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 3501
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #32 am: 01 März 2015, 00:17:14 »
sind GIT-Kenntnisse mandatory?
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #33 am: 01 März 2015, 01:25:13 »
nö, letztendlich ist das auch nicht schwieriger als svn.

-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2952
  • ~ Challenging Innovation ~
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #34 am: 02 März 2015, 10:21:26 »
Ich bringe recht gute Git Erfahrungen mit und könnte testen.
FHEM-Module: ENIGMA2, GEOFANCY, ONKYO_AVR, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

Docker-FHEM 5.10dev auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #35 am: 02 März 2015, 20:19:29 »
ja und? Mach doch.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2952
  • ~ Challenging Innovation ~
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #36 am: 02 März 2015, 20:22:19 »
Ich weiß ja leider nicht, was du getestet haben möchtest. Mit einem einfachen Checkout dürfte dir wohl nicht geholfen sein?
Zumal http://fhem.betateilchen.de nicht erreichbar scheint.
FHEM-Module: ENIGMA2, GEOFANCY, ONKYO_AVR, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

Docker-FHEM 5.10dev auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #37 am: 02 März 2015, 21:34:36 »
Da Du offenbar des Lesens (oder des Verstehens) von einfachsten Forumbeiträgen hier im Thread nicht mächtig bist, scheidest Du als Tester ohenhin aus. Sorry.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2952
  • ~ Challenging Innovation ~
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #38 am: 04 März 2015, 09:01:09 »
Sei doch nicht immer so biestig, nur weil man dich darauf hinweist, dass dein Webserver temporäre Probleme beim Zugriff über SSL hatte... aber zugegeben, es hat mich amüsiert.


Ich habe die Nachrichten hier sehr wohl aufmerksam gelesen. Inzwischen hast du jedoch alle relevanten Infos durchgestrichen, sie sollen wohl obsolete sein.
Aber auch davor war meine Frage gerechtfertigt: Was hast du davon, wenn jemand einfach nur was auscheckt? Das kannst du auch selbst testen, oder nicht? Oder ging es dir darum, dass ich mich in einer geheimnisvollen E-Mail an dich wende, statt öffentlich auf den Beitrag zu antworten?
FHEM-Module: ENIGMA2, GEOFANCY, ONKYO_AVR, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

Docker-FHEM 5.10dev auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #39 am: 15 März 2015, 17:37:08 »
culfw wird seit heute auch regelmäßig als eigenes git repository auf git.fhem.de migriert. Die Aktualisierung erfolgt allerdings nur einmal pro Tag, da sich dort nicht so häufig Änderungen ergeben.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline Markus Bloch

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 3501
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #40 am: 15 März 2015, 17:48:10 »
Wie ist denn eigentlich hier nu die offizielle Marschrichtung?

Bleiben wir bei Sourceforge, oder wird FHEM (und evtl. auch culfw) wo andershin umziehen und dabei evtl. auch auf git schwenken?

Wäre ganz interessant zu wissen.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #41 am: 15 März 2015, 17:55:13 »
Kommt Zeit, kommt Rat git ...

Nur nicht drängeln, ich vermute, Rudi wird sich dem recht eindeutigen Votum seiner Umfrage nicht auf Dauer verweigern.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline Christoph Morrison

  • Developer
  • Full Member
  • ****
  • Beiträge: 441
    • Private Website
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #42 am: 30 September 2018, 16:05:52 »
*rauskram*

Wieso gibt es git.fhem.de eigentlich nicht mehr?

Zitat
Nur nicht drängeln, ich vermute, Rudi wird sich dem recht eindeutigen Votum seiner Umfrage nicht auf Dauer verweigern.

Da hat er sich nun aber über drei Jahre erfolgreich widersetzt.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19536
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #43 am: 30 September 2018, 16:54:31 »
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.
Zustimmung Zustimmung x 1 Liste anzeigen

Offline smurfix

  • Developer
  • Full Member
  • ****
  • Beiträge: 272
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #44 am: 30 September 2018, 17:30:36 »
Naja. Meine Meinung: verstehe die dahinter liegenden Konzepte, und es ist logischer als alles Andere was man so findet.

Lokale Anpassungen mit SVN nachzuziehen ist um Einiges arbeitsaufwändiger (und fehlerträchtiger) als mit git. Meine Erfahrung …
Gefällt mir Gefällt mir x 1 Zustimmung Zustimmung x 1 Liste anzeigen

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19536
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #45 am: 30 September 2018, 17:33:03 »
Das mag sein, aber lokale Anpassungen zu foerdern ist zZt. nicht meine Prioritaet.

Offline Christoph Morrison

  • Developer
  • Full Member
  • ****
  • Beiträge: 441
    • Private Website
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #46 am: 30 September 2018, 20:32:00 »
Das mag sein, aber lokale Anpassungen zu foerdern ist zZt. nicht meine Prioritaet.

Das ist schade, wirklich. Das koppelt FHEM nämlich von den Ideen der Leute ab, die keinen Bock auf den Driss mit Schreibrechten im Subversion-Repository / Maintainer-Bettelei haben.

Ich sehe die Vorteile von Git darin, dass es ein offeneres Modell als ein zentrales SVN-Repository ist, das vom Rest der Welt quasi abgeschottet ist. Setzt man Git in einem forking workflow ein, ist die Hürde von außerhalb Code beizutragen deutlich niedriger.

Ich möchte das mal mit den zentralisierten Workflow, der hier genutzt wird (gleichberechtigter Zugriff auf ein gemeinsames Repository), an einem Beispiel vergleichen:

Ich habe vor einer Weile ein paar Bugs in CUPS gefixt. Ich bin kein Entwickler in dem Projekt, habe also keinen schreibenden Zugriff auf das CUPS-Repository auf Github. Ich habe einfach einen Fork gemacht, die Bugs gefixt und den Projektentwicklern einen pull request, d.h. die Aufforderung/Bitte meinen Code aufzunehmen, geschickt. Das haben sie auch getan, nach dem sie den Code für gut befunden haben (vermute ich). Änderungen die ich gerne an FHEM machen möchte (und zwar nicht nur lokal), kann ich auf einem Klon des Repositories machen, aber dazu muss ich  dann erst einen Schreibzugriff beantragen, aber dann darf ich vielleicht auf ein Modul gar nicht schreibend zugreifen. Dumm wenn man einen Bug fixen will, der irgendwo ist, wo man keine Schreibrechte hat. Also muss ich einen Patch machen / die Änderung beschreiben und den Maintainer kontaktieren, der dann hoffentlich reagiert und den Patch hochschiebt. Das alles ist viel mehr Aufwand als einfach einen pull request per Mausklick nach einer Sichtung zu akzeptieren, wie es bei Git wäre - Aufwand für beide Seiten, der nicht in das Schreiben von Code fließt, sondern in dumme Bürokratie.

Wenn ich außerdem gerade mal ins SVN gucke finde ich da archäologisch sicher spannende branches von 2007/2008, die aber nie hätten dort landen sollen. Sowas kann man auch geschickt umgehen in dem man den Leuten ihr eigenes FHEM-Git-Repository lässt aus dem man dann über pull requests die interessanten Teile übernimmt.
Gefällt mir Gefällt mir x 4 Liste anzeigen

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #47 am: 30 September 2018, 20:40:51 »
Zu diesem Thema ist es völlig unnötig, mit Rudi zu diskutieren, dazu ist er zu sehr in der Vergangenheit verwurzelt und zeigt erfahrungsgemäß wenig Bereitschaft, sich mit irgendwelchen neuen Technologien und deren Vorteilen unvoreingenommen zu befassen.

Alleine diese Aussage

mAn bietet git Features, die bei FHEM nicht benoetigt werden, und ist selten unlogisch in der Benutzung.

belegt diese grundsätzliche Ablehnung eindrucksvoll.

verstehe die dahinter liegenden Konzepte, und es ist logischer als alles Andere was man so findet.

*unterschreib*
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline smurfix

  • Developer
  • Full Member
  • ****
  • Beiträge: 272
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #48 am: 30 September 2018, 21:04:53 »
Das mag sein, aber lokale Anpassungen zu foerdern ist zZt. nicht meine Prioritaet.
Na gut, dann streiche "Lokale Anpassung" und ersetze "Bugfix" und "Erweiterung". Die förderst du damit nämlich auch nicht, zumal Erstere irgendwie die Voraussetzung für Letztere darstellen.

Ich habe keine Ahnung, ob diese Einstellung mehr als einen möglichen Mitarbeiter (mich …) dazu gebracht hat, stattdessen Home Assistant zu verwenden … aber ich nehme es an.

Ich spiele jedenfalls lieber in Sandkästen, in denen ich das Gefühl habe, willkommen zu sein.

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17210
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #49 am: 30 September 2018, 21:13:26 »
Na gut, dann streiche "Lokale Anpassung" und ersetze "Bugfix" und "Erweiterung". Die förderst du damit nämlich auch nicht, zumal Erstere irgendwie die Voraussetzung für Letztere darstellen.

Ich habe keine Ahnung, ob diese Einstellung mehr als einen möglichen Mitarbeiter (mich …) dazu gebracht hat, stattdessen Home Assistant zu verwenden … aber ich nehme es an.

Ich spiele jedenfalls lieber in Sandkästen, in denen ich das Gefühl habe, willkommen zu sein.

Sehe ich anders. Du und auch jeder andere Entwickler sind herzlich willkommen. Doch deswegen muss man noch lange nicht nach Deiner Pfeife oder Deinem Wohlwollen handeln. Man kann diskutieren aber sollte nicht versuchen zu erzwingen, oder wie Du gar zu erpressen  >:(
« Letzte Änderung: 30 September 2018, 21:21:47 von CoolTux »
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier
kein Support für cfg Editierer

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #50 am: 30 September 2018, 21:18:31 »
Nachtrag

mAn bietet git Features, die bei FHEM nicht benoetigt werden

das ist in svn aber nicht anders, da gibt es mindestens genau so viele Features, die in FHEM nicht benötigt genutzt werden...
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline smurfix

  • Developer
  • Full Member
  • ****
  • Beiträge: 272
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #51 am: 30 September 2018, 21:34:01 »
Ich habe nicht vor, irgendwen zu "erpressen". Ich schreibe nur, wie ich mich hier fühle bzw. gefühlt habe, und was ich daraus für Konsequenzen gezogen habe. (SVN ist nicht der einzige Grund; die

Wenn du daraus eine Erpressung ableitest, dass ich *sage* dass ich heutzutage keinen Bock auf den Terz mit SVN und Patches mehr habe, der sich mit git viel einfacher managen lässt, dann ist das ehrlich gesagt nicht mein Problem.

Wie ich Rudi bereits vor zweieinhalb jahren antwortete: Manchmal passen Arbeitsstile nicht wirklich zusammen. Die Gründe anzuführen, wieso das so ist (SVN vs. git, und die unterschiedlichen Arbeitsstile die diese Tools ermöglichen, ist ein großer Teil davon, aber nicht der einzige Knackpunkt – der Rest passt nicht in dieses Thema), wird ja wohl erlaubt sein.

Offline Christoph Morrison

  • Developer
  • Full Member
  • ****
  • Beiträge: 441
    • Private Website
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #52 am: 30 September 2018, 21:41:44 »
Sehe ich anders. Du und auch jeder andere Entwickler sind herzlich willkommen. Doch deswegen muss man noch lange nicht nach Deiner Pfeife oder Deinem Wohlwollen handeln. Man kann diskutieren aber sollte nicht versuchen zu erzwingen, oder wie Du gar zu erpressen  >:(

Inwiefern droht dir smurfix irgendein Übel an und was sollte das für eins sein? Er schreibt ja, dass er für sich den Schluss gezogen hat, dass ihm das aktuelle Modell nicht funktioniert und dass er davon ausgeht, dass es anderen Leute ähnlich geht - und er deswegen die Konkurrenz bevorzugt (so habe ich es zumindest verstanden).

Für mich ist das aktuelle Modell einfach nutzlos ineffizient, deswegen halte ich mich mit Code zurück, den ich beisteuern könnte. Dann sind halt irgendwelche Sachen in meiner angepassten FHEM-Installation anders, gefühlt besser, aber ich kann das nicht mal wirklich effizient den Leuten zu kommen lassen, die auch interessiert wären (wie wir gestern bei dem Treffen der FHEM-UG Gütersloh/OWL mehrfach festgestellt haben). Selbst wenn ich meine Patches auf die offizielle Codebasis anwende, sind sie doch mit dem nächsten Update wieder weg, außer ich schließe jede andere Weiterentwicklung aus; mergen ist ja so nicht, weil ich keine lokale, getrennte Kopie des Repositories betreiben kann.

Bisher habe ich übrigens außer "Wir machen schon immer Subversion" noch kein Pro-Argument für Subversion gelesen, just saying.

(Typo korrigiert)
« Letzte Änderung: 30 September 2018, 21:47:00 von Christoph Morrison »

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19536
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #53 am: 30 September 2018, 23:04:23 »
Ich sehe zwei unterschiedliche Szenarien:

1. Weitergabe der Aenderungen an dem Maintainer.
Pull requests verleiten dazu, das Problem auf privaten Kanaelen zu diskutieren. Man kann genausogut einen Patch hier im Forum posten, damit der Maintainer es integrieren kann. Dann ist es oeffentlich dokumentiert, zusammen mit den Pro- und Kontra-Argumenten, und Benutzer koennen es vor dem Integrieren testen.

2. Weitergabe der Aenderungen an "Kollegen".
Lokale Aenderungen kann man mit svn auch behalten, nur die Weitergabe einzelner Aenderungen wird kompliziert, wenn man mehrere solche Aenderungen hat. Und damit habe ich kein Problem, ich will beim Support nicht herausfinden muessen, wessen Patches noch dazugekommen sind. Wenn der Maintainer deine Aenderungen nicht will, steht es dir frei, das modifizierte Modul unter deinem Namen anzubieten.


Zitat
Bisher habe ich übrigens außer "Wir machen schon immer Subversion" noch kein Pro-Argument für Subversion gelesen, just saying.
Aenderungen des Versionsystems sind nicht ohne Aufwand, spreche aus Erfahrung, FHEM hat mit CVS angefangen.
« Letzte Änderung: 30 September 2018, 23:06:58 von rudolfkoenig »

Offline Christoph Morrison

  • Developer
  • Full Member
  • ****
  • Beiträge: 441
    • Private Website
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #54 am: 01 Oktober 2018, 00:13:45 »
Zitat
Pull requests verleiten dazu, das Problem auf privaten Kanaelen zu diskutieren. Man kann genausogut einen Patch hier im Forum posten, damit der Maintainer es integrieren kann. Dann ist es oeffentlich dokumentiert, zusammen mit den Pro- und Kontra-Argumenten, und Benutzer koennen es vor dem Integrieren testen.

Jeder pull request (PR) kann annotiert und öffentlich diskutiert werden, siehe z.B. (völlig willkürlich): https://github.com/apple/cups/pull/5261
Am Ende steht dann eine Entscheidung ob der PR akzeptiert wird oder nicht, die dann bei einem oder mehreren Maintainern liegt. Das ist doch deutlich öffentlicher als jetzt, wo die Kommunikation vielleicht gar nicht oder privat oder sonst wo stattfindet, mal von den ganzen Features wie milestones / releases / öffentliches bugtracking etc. abgesehen, die wir jetzt nicht haben oder nicht nutzen.

Zitat
Lokale Aenderungen kann man mit svn auch behalten,

Und kann nicht mehr problemlos updaten sobald der svn-automerge nicht mehr richtig funktioniert (was früher oder später immer passiert, btdt), vom FHEM update mal ganz zu schweigen (ja ich kenne die Möglichkeiten des exclude).

Zitat
nur die Weitergabe einzelner Aenderungen wird kompliziert, wenn man mehrere solche Aenderungen hat. Und damit habe ich kein Problem, ich will beim Support nicht herausfinden muessen, wessen Patches noch dazugekommen sind.

Inwiefern müsstest du z.B. für CM's FHEM clone Support leisten? Im Idealfall holt sich ein hypothetischer User einen "Patch" als PR in sein eigenes FHEM, das ein Fork vom offiziellen FHEM ist. Die Antwort auf Leute mit eigenem FHEM-Klon ist dann: Kein Support für deinen crooked clone.

Zitat
Wenn der Maintainer deine Aenderungen nicht will, steht es dir frei, das modifizierte Modul unter deinem Namen anzubieten.

Ja und das funktioniert sogar ohne den Update-Mechanismus von FHEM zu brechen wenn der Maintainer so schlau war sein Modul nicht in das Subversion-Repo zu geben, sondern bei Github oder so geblieben ist. Wenn ich aber was am Kern ändern möchte, du/der Maintainer das nicht akzeptierst, andere das aber sehr wohl wollen, hört der Spaß bei etwas komplexeren Änderungen (siehe oben) schnell auf.

Zitat
Aenderungen des Versionsystems sind nicht ohne Aufwand, spreche aus Erfahrung, FHEM hat mit CVS angefangen.

Ich hab in meiner beruflichen Laufbahn als Softwareentwickler, DevOps und Projektmanager sicher mehrere dutzend Projekte (mit-)migriert, oftmals genau in diesem Setting (svn → git). Vorteil: Es gibt bereits einen Git-Mirror von FHEM, der ist halt nicht offiziell, spiegelt den Schrott der in /branches liegt mit (und der ist einen Tag hinten dran). Aber es geht offensichtlich und da ein Großteil der Projekte und u.a. auch der Linux-Kernel, der ja nun nicht gerade klein oder unbedeutend ist, auf Git setzen, gibt es sicher auch Möglichkeiten die build queue dahinter entsprechend umzugestalten. Ich bringe mich da auch gerne mit ein.
Gefällt mir Gefällt mir x 4 Liste anzeigen

 

decade-submarginal