SVN Commit Message Links auf Forum-Beiträge

[Markus Bloch]

Hallo zusammen,

mir ist in der Vergangenheit vermehrt aufgefallen, dass Entwickler versuchen einen ganz bestimmten Beitrag aus dem Forum in der Commit-Message zu verlinken um sie im Trac wieder aufrufen zu können. Aktuell funktioniert im Trac nur das verlinken eines kompletten Threads:

Bsp:  https://forum.fhem.de/index.php/topic,19621.0.html kann man in der Commit-Message folgendermaßen verlinken: Forum: #19621:

MODULNAME: updated xxx to fix problem yyyy (Forum: #12345)

Dabei wird dieses Pattern im Trac erkannt und als Link zum Forum umgewandelt: https://forum.fhem.de/index.php/topic,12345.0.html

Nun habe ich im Trac immer mal wieder Versuche gesehen, wo Entwickler einen bestimmten Beitrag innerhalb eines Threads verlinken wollten. Dies funktioniert aktuell nicht, da ich mich damals nicht für eine Syntax entscheiden konnte, wie man das am effizientesten darstellt. Man brauch auf jedenfall die Thread-ID und die Beitrags-ID (index.php/topic,19621.msg132314.html)

Da dies euch als Entwicklern unterstützen soll, Änderungen einfacher nachvollziehen zu können, möchte ich euch Fragen, was eure Wünsche/Anregungen/Vorschläge zu diesem Thema sind?

Welche Ersetzungen/Schematas würdet ihr euch wünschen um Informationen/Forumsbeiträge effizient verknüpfen zu können?

Viele Grüße

Markus

[betateilchen]

Hallo Markus,
Ich finde die Angabe der Thread-"Nummer" völlig ausreichend.

[Benni]

Ansonsten bräuchte man halt irgend einen Trenner zwischen Thread- und Message-ID

hier beispielsweise das Komma:

Code Auswählen Erweitern


MODULNAME: updated xxx to fix problem yyyy (Forum: #12345,67890)


Grundsätzlich bin ich da aber auch eher betateilchens Meinung. Meistens ist doch ein längerer Diskussionsverlauf relevant, denn ein einzelner Beitrag.

Wobei bei so manchem Monster-Thread wäre es schon nicht schlecht, wenn man in etwa an die richtige Stelle geführt würde Allerdings gibt es ja auch noch das Datum anhand dessen man den Zeitraum entsprechend einschränken kann.

[dev0]

Code Auswählen Erweitern


MODULNAME: updated xxx to fix problem yyyy (Forum: #12345,67890)


(Forum: #12345,67890) fände ich sehr hilfreich.

[betateilchen]

Diejenigen Anwender, die verstehen, was diese kryptische Angabe bedeutet, wissen auch, wie sie den passenden Beitrag ohne diese Angabe finden können.

• Als Entwickler habe ich TRAC noch nie benutzt (und nie gebraucht).
• Schätzungsweise 99,673% aller normalen FHEM-Nutzer wissen überhaupt nicht, was TRAC ist und werden einen Link auf einen bestimmten Beitrag nie entdecken.

Lasst uns doch bitte nicht (wieder einmal) Lösungen für Probleme überlegen, die eigentlich gar nicht existieren.

[rudolfkoenig]

Ich behaupte mit (Forum: #xxxx) im SVN Kommentar angefangen zu haben, ohne zu wissen, ob ein Programm damit was anfangen kann. Ich verwende es inzwischen konsequent, damit ich spaeter via svn blame, svn log und Forumsbeitrag rausfinden kann, was ich bei der Aenderung gedacht habe. Die msg Angabe im Komentar verwende ich nicht, in einem langen Thread (was ich eh nicht toll finde) reicht der Eincheck-Zeitpunkt.

Trac verwende ich (noch?) nicht. Im trac, mit blame, wird zwar der Kommentar als Mouseover ueber die Version eingeblendet, das (Forum #xxxx) ist aber (auch wg. mouseover) nicht klickbar, kopierbar, und manchmal auch abgeschnitten, insofern ist dafuer eine komplexere Link-Unterstuetzung vergeblich.

Will sagen: mir wuerde eine Erweiterung nichts bringen.

Ich meine es gelesen zu haben, dass manche Benutzer zusaetzlich oder statt CHANGED die SVN Kommentare lesen. Fuer sie ist diese Link-Umwandlung sinnvoll, falls sie die Kommentare mit trac lesen. Aber fuer diesen Fall waere es mAn besser, wenn man beim update check CHANGED komplett anschauen kann, und dabei diese Links generiert werden. Dabei koennte man den Text auch nach den verwendeten Modulen filtern. Ich wuerde am liebsten CHANGED aufgeben, und das Log aus den SVN Kommentaren generieren, damit ich den gleichen Text nicht zweimal eingeben muss. Das letzte mal wo ich das vorgeschlagen habe, gabs aber Widerstand dagegen. Was ist Eure Meinung dazu?

[betateilchen]

Ich wuerde am liebsten CHANGED aufgeben, und das Log aus den SVN Kommentaren generieren, damit ich den gleichen Text nicht zweimal eingeben muss. Das letzte mal wo ich das vorgeschlagen habe, gabs aber Widerstand dagegen. Was ist Eure Meinung dazu?

Die Idee an sich ist gut, ist aber aufgrund mangelnder Disziplin beim Einchecken von Modulen zum Scheitern verurteilt.
Wenn eine Moduländerung am gleichen Tag mehrfach kurz hintereinander eingecheckt wird, weil man irgendwo noch ein Leerzeichen oder ein Komma vergessen hat, hast Du auch mehrfach einen commit-Kommentar, der in den meisten dieser Fälle keine hilfreiche Information enthält.

[zap]

Hallo Markus,

ich finde eine MessageID sehr hilfreich, da viele Anwender dazu neigen, ihre Frage nicht in einem separaten Thread zu stellen sondern an den Ankündigungsthread eines Moduls anzuhängen. Dieses Verhalten ist eine Eignart des FHEM Forums, die mir in keinem anderen Forum begegnet ist, in dem ich aktiv bin.

Ich habe die Anwender meines Moduls HMCCU schon mehrfach gebeten, bei Fragen einen separaten Thread zu eröffnen. Leider hält sich daran so gut wie niemand. Dadurch entstehen die Threads mit mehr als 100 Seiten, in denen keiner mehr was findet.

Insofern ist die Angabe der MessageID eher ein Workaround für dieses Problem, allerdings ein notwendiger, um zumindest einigermaßen den Überblick zu behalten.

VG Dirk

[rudolfkoenig]

Die Frage ist nicht, ob man eine Message-Id im Kommentar angeben darf oder nicht, sondern ob es jemandem hilft, wenn trac die direkte Verlinkung unterstuetzt, und da sehe ich _fuer mich_ keinen Vorteil.

Btw. man kann die Anwender schnell erziehen, indem man mitteilt, dass man den Fall nur dann bearbeitet, falls der Problemsteller ein neues Thread oeffnet. Endlose Threads sind nicht nur fuer die SVN-Kommentare stoerend, sondern fuer jeden, der mit diesem Modul ein Problem hat.

[betateilchen]

Endlose Threads sind nicht nur fuer die SVN-Kommentare stoerend, sondern fuer jeden, der mit diesem Modul ein Problem hat.

Und für jeden Maintainer eines Moduls auch.