FHEM Forum

Zitat von: Prof. Dr. Peter Henning am 20 September 2014, 20:21:44
Wie immer, wenn man auf ein Mirakel gehofft hat und es nicht gekommen ist

Apropos "hoffen auf Mirakel" ... ich hoffe ja auch immer noch auf das Mirakel, dass irgendwann alle Entwickler dazu übergehen, beim Einchecken irgendwelcher Änderungen endlich einen Kommentar dazuzuschreiben. Oder aber, dass der SVN-Verantwortliche es irgendwann schafft, das Einchecken von Änderungen ohne einen solchen Kommentar zu unterbinden.

Wieso komm ich da jetzt ausgerechnet bei Dir drauf? Keine Ahnung ;)

(http://up.picr.de/19577320pw.png)

am besten nicht nur irgendeinen Kommentar, sondern auch eine Angabe, welche/s Modul/e von dem commit betroffen sind. Die automatischen Posts unter 'FHEM Code changes' enthalten nur(!) den Kommentar ohne Angabe der veränderten Dateien. Ist zwar nicht wirklich kriegsentscheidend (dafür gibt es ja die entsprechenden SVN-/Git-Tools), würde aber sehr helfen immer auf einen Blick zu sehen, ob das für einen selber interessant/wichtig ist oder nicht.

Gruß,

Norbert

Zitat von: ntruchsess am 20 September 2014, 22:03:46
am besten nicht nur irgendeinen Kommentar, sondern auch eine Angabe, welche/s Modul/e von dem commit betroffen sind.

Das ist sinnvoll.
Ich schreibe sie so: 36_JeeLink.pm: Added EMT7110 to Clients and MatchList
Manche so: 99_GetState.pm - renamed to match Initialize
Und manche so: YAMAHA_AVR: fix return of next scheduled timestamp for statusRequest

Zumindest eine Richtline (ob Doppelpunkt oder Bindestrich ist nun auch nicht kriegsentscheidend aber einheitlicht immer sinnvoll) wäre nicht schlecht.
Aber alles ist besser als leer.

Zitat von: betateilchen am 20 September 2014, 21:52:34Oder aber, dass der SVN-Verantwortliche es irgendwann schafft, das Einchecken von Änderungen ohne einen solchen Kommentar zu unterbinden.

Extrem sinnvoll.
Falls man in sourceforge hooks definieren kann:
Auf meinen SVN-Servern verwende ich diesen serverseitigen pre-commit hook:
"%VISUALSVN_SERVER%\bin\VisualSVNServerHooks.exe" case-insensitive -t%2 %1

@echo off
::
:: Stops commits that have empty log messages.
::

setlocal

set REPOS=%1
set TXN=%2

rem check for an empty log message
"%VISUALSVN_SERVER%\bin\svnlook" log %REPOS% -t %TXN% | findstr . > nul
if %errorlevel% gtr 0 (goto err) else exit 0

:err
echo. 1>&2
echo Your commit has been blocked because you didn't give any log message 1>&2
echo Please write a log message describing the purpose of your changes and 1>&2
echo then try committing again. -- Thank you 1>&2
exit 1

Habe mit einem pre-commit hook angefangen, ab sofort sind Kommentare mit dem Namen der betroffenen Datei (oder sowas aehnliches) zwingend:

#!/bin/sh

exec 1>&2

REPOS="$1"
TXN="$2"

# Make sure that the log message contains some text.
SVNLOOK=/usr/bin/svnlook
$SVNLOOK log -t "$TXN" "$REPOS" | \
egrep -q '^.*:.*'
if test "$?" -ne 0; then
  echo "A FHEM SVN comment must have the following format"
  echo "  module: text-describing-the-change"
  echo "or"
  echo "  module: text-describing-the-change (Forum #<forum.fhem.de threadnumber>)"
  exit 1;
fi
exit 0


Falls jemand noch einen doku-pruefer ala commandref_join spendiert, dann baue ich das ein.

ich bin sehr für den zwang zu einem kommentar beim einchecken.

den modul namen oder auch nur einen : als zwingend vorauszusetzen finde ich aber keine gute idee. der name geht eindeutig aus dem kontext hervor und ist bei kommits die mehr als ein file betreffen völlig unpassend.

wenn es eine prüfung sein soll die mehr als das vorhanden sein eines kommentars prüft wäre eine mindestlänge von zwei oder drei worten besser.

für die prüfung auf dokumentation bitte dran denken das nur die \d\d_.*.pm files eine solche haben.

Zitat von: justme1968 am 21 September 2014, 10:21:54
den modul namen oder auch nur einen : als zwingend vorauszusetzen finde ich aber keine gute idee. der name geht eindeutig aus dem kontext hervor

Nein, der Name geht eben nicht immer eindeutig aus dem Kontext hervor.
Und es ist absolut kein Problem, denn commit-Kommentar auch mehrzeilig anzugeben, dann kann man auch bei mehreren Files, die man gleichzeitig eincheckt, für jedes File den Namen angeben und einen Kommentar pro File angeben.

der kontext sind alle files die bei einem commit gleichzeitig mit dem gleichen kommentar eingecheckt werden. und der ist eindeutig.

den modul namen noch mal extra und von hand zwingend anzugeben ist redundant und schafft zusätzliches potential für konflikte. was versprichst du dir davon? erst recht wenn es sich wie bei den aller meisten check-ins um genau ein file handelt.

gleichzeitig eingecheckte files sollten einen logischen zusammenhang haben und normalerweise (es gibt ausnahmen) den gleichen kommentar. was soll es bringen den gleichen kommentar mehrfach anzugeben?

Falls man ein SVN Client auspackt, dann kann man natuerlich genau untersuchen, welche Dateien betroffen sind.

Es geht mir hier darum, dass die per email versendete Commit-Texte, die auch hier in Forum auftauchen, ohne weitere Arbeit zugeordnet werden koennen. Den Bezug zu einem Forums-Thread finde ich deswegen wichtig, weil nach eine Weile man (==ich) den eigentlichen und nicht kurz beschreibbaren Grund der Aenderung vergisst.

die begründung ist nachvollziehbar. wenn svn das her gibt sollte die liste der betroffenen files automatisch in die mail eingefügt werden. redundant und dann noch von hand ist einfach blöd.

den link auf den forums thread find ich gut.

Ich habe keine Ahnung, wie man den Kommentar aendern kann, aber ich bin offen fuer Patches :)

Zitat von: justme1968 am 21 September 2014, 10:34:53
den modul namen noch mal extra und von hand zwingend anzugeben ist redundant und schafft zusätzliches potential für konflikte. was versprichst du dir davon?

Es geht schlicht darum, dass auch fhem-User, die nicht mit einem SVN/git-Client arbeiten, in dieser extra eingerichteten Forumrubrik http://forum.fhem.de/index.php/board,57.0.html eine sinnvolle Information vorfinden und nicht nur sowas:

(http://up.picr.de/19581105vl.jpg)

Aber dieser Grund wurde ja schon mehrfach hier angeführt.

den grund habe ich inzwischen verstanden und kann ihn nachvollziehen. das ändert nichts daran das ich der meinung bin das es nicht der richtige weg ist den namen des moduls von hand als pflichtfeld vorzusehen.

so etwas gehört automatisiert in den commit hook oder in des script das die mails verschickt.

ich weiss noch nicht ob und wie das mit svn geht aber ich schaue danach. vielleicht gibt es ja jemanden der schon eine idee dazu hat.

Mein Client schlägt - auf Wunsch - die Namen der im commit enthaltenen Dateien automatisch für den commit-Kommentar vor...

Könnte man die betroffenen Dateien eventuell da hinzufügen, wo es zu einem Forumsbeitrag wird?
Dann müsste man es nicht mit angeben.
Aus SVN könnte es so geholt werden:

svn log https://svn.code.sf.net/p/fhem/code/trunk/fhem -v -r 6583
------------------------------------------------------------------------
r6583 | rudolfkoenig | 2014-09-20 19:15:08 +0200 (Sa, 20 Sep 2014) | 3 lines
Changed paths:
   M /trunk/fhem/FHEM/01_FHEMWEB.pm
   M /trunk/fhem/FHEM/98_SVG.pm

adding plotEmbed parameter for iOS 8


------------------------------------------------------------------------

Oder genau diese Information in den body des Breitrags übernehmen, anstatt den Titel zu wiederholen.

Zitat von: rudolfkoenig am 21 September 2014, 10:00:24
Habe mit einem pre-commit hook angefangen, ab sofort sind Kommentare mit dem Namen der betroffenen Datei (oder sowas aehnliches) zwingend:

sowas kommt von sowas:


a little improvement: use device name if no alias defines (for text/html output methods)
feature: HTML/Text output for SYSMON-CloneDummies
feature: Method for titled HTML/Text output


Hauptsache, es steht ein Doppelpunkt drin?!

meine rede. wenn es nicht automatisch geht wird es umgangen.

Jungs, wenn Kritik, dann bitte konstruktiv (== als Patch).

Immerhin kann man jetzt keine Leeren Kommentare eingeben, und man kriegt (manchmal) auch einen Hinweis, wie man das gerne haette. Ich finde das ist besser als garnix.

Ich finde das auch besser als gar nix. Und meine Anmerkung war auch in keiner Weise gegen Dich oder Deine Bemühungen gerichtet, die Sache in den Griff zu bekommen.

Mein Vorschlag in Beitrag #14 war schon irgendwie Konstruktiv, nur vermag ich ohne die Routine, die commits zu Beiträgen macht, zu kennen, nicht zu sagen, ob und wie es gehen würde.

Falls ich die irgendwo anschauen kann, beurteilen ich, ob ich dafür einen Patch machen kann.

Ich habs doch in meinem Beitrag vom 21 September 2014, 10:00:24 gepostet.
Wo sieht man denn einen Beitragsnummer?

Zitat von: rudolfkoenig am 24 September 2014, 16:28:03
Wo sieht man denn einen Beitragsnummer?

(http://up.picr.de/19616914pb.png)

Die Nummer steht hinter "Antwort" ;)

Zitat von: rudolfkoenig am 24 September 2014, 16:28:03
Ich habs doch in meinem Beitrag vom 21 September 2014, 10:00:24 gepostet.

Ich meinte nicht den Hook.
Dann versuche ich meine Idee nochmal zu beschreiben:

Aus den commits in SVN werden von irgend einer Routine Eintäge im Forum gemacht (FHEM Forum » FHEM - Entwicklung » FHEM Code changes)

Dabei bekommt der Beitrag im Forum als Titel die Message des commit
Beispiel:
adding plotEmbed parameter for iOS 8

und in den Body kommt sie gleich noch zweimal rein.
Beispiel:

adding plotEmbed parameter for iOS 8

adding plotEmbed parameter for iOS 8View Changes

Source: adding plotEmbed parameter for iOS 8

Die Idee war, die Routine, die das macht (und von der ich nicht weiß, wo sie ist) gem. meinem Beipiel vom 21 September 2014, 13:34:47 anzupassen dass der body des forum-Beitrags so aussieht:
------------------------------------------------------------------------
r6583 | rudolfkoenig | 2014-09-20 19:15:08 +0200 (Sa, 20 Sep 2014) | 3 lines
Changed paths:
   M /trunk/fhem/FHEM/01_FHEMWEB.pm
   M /trunk/fhem/FHEM/98_SVG.pm

adding plotEmbed parameter for iOS 8
------------------------------------------------------------------------


Dann wäre es beim Commit nicht erforderlich, dass man die geänderten Files mit angibt.
Und man kann im Beitrag auch noch sehen, welche Dateien hinzugefügt, geändert oder gelöscht wurden.

ZitatDann versuche ich meine Idee nochmal zu beschreiben:

Ich brauche keine Ideen (davon habe ich genug selber, z.Bsp. koennte man CHANGED automatisch generieren, und die commandref_join Pruefung ausfuehren), sondern Patches.

es ging weniger um die idee sondern um die frage wo die mails generiert werden. ist das selbst gebaut? ein sourceforge feature? gehört es zur forensoftware?

Ich vermute Sourceforge, weil ich auch fuer culfw Aenderungen eine Nachricht kriege.
Wie das wiederum ins Forum kommt, weiss ich nicht.

Zitat von: rudolfkoenig am 05 Oktober 2014, 19:48:26
Ich brauche keine Ideen (davon habe ich genug selber, z.Bsp. koennte man CHANGED automatisch generieren, und die commandref_join Pruefung ausfuehren), sondern Patches.

Ich wollte die Idee schildern und in Erfahrung bringen, wo ich eventuell was dafür tun könnte.
Ist jetzt aber nicht so, dass ich vor lauter Langweile mich nicht auch mit anderen Dingen beschäftigen könnte...

Zitat von: rudolfkoenig am 05 Oktober 2014, 19:52:15
Ich vermute Sourceforge, weil ich auch fuer culfw Aenderungen eine Nachricht kriege.

Ein Sourceforge-Feature alleine kann das nicht sein, denn die Meldungen kommen über einen Administrator-Account ins Forum.

Patches kann man allerdings nur bauen und bereitstellen, wenn man das "Original" zur Verfügung hat ;)

Nicht unbedingt:
rsync -av svn.code.sf.net::p/fhem/code fhem
(mache ich taeglich) und dann
svnlook log -r 6592 fhem/code
usw.
Die zu modifizierenden Dateien sind in fhem/code/hooks, diese muss ich zum Schluss vermutlich dann selbst via ssh installieren.

Wieso gibt es eigentlich seit 30.09. hier -> http://forum.fhem.de/index.php/board,57.0.html keine Aktualisierungen mehr?