tessarakt - das vierdimensionale B-L-O-G » Informatik

Patch-Queue – wie organisieren?

Jens — Fri, 13 Jan 2012 13:47:36 +0000

Ich habe in letzter Zeit angefangen, Patches für ein Open-Source-Projekt (Boost, konkret die Graph Library) zu erstellen. Da ich selbst dort keine Commit-Rechte habe, bin ich darauf angewiesen, dass Entwickler mit solchen Rechten meine Änderungen für mich einchecken. Und da die auch nicht 24h verfügbar sind, dauert es eine Weile, bis die Sachen eingecheckt sind. Ich will aber ggf. mit Folgeänderungen weitermachen, die die vom ersten Patch geänderten Stellen nochmals ändern. Und da geht dann schnell das Chaos los

Bevor jetzt gleich tolle Tipps kommen, dass das mit diesem oder jenem Versionsverwaltungssystem ja alles ganz einfach geht: Das Chaos dürfte zuallererstmal dadurch verursacht sein, dass ich gar nicht so recht weiß, was ich von einer Lösung erwarte. Der erste Schritt ist also eine saubere Anforderungsanalyse:

Diff gegen noch nicht eingecheckte Patches: Ich möchte sehen, welche Änderungen sich in meiner working copy befinden, die über die bereits erzeugten (aber noch nicht eingecheckten) Patches hinausgehen. Die Differenz zum Trunk reicht also nicht.
Status von Patches: Ich muss Patches als erledigt markieren können, wenn sie eingecheckt sind.
Zusammenfassen von Patches: Wenn ich Patches noch nicht eingesendet habe (oder ggf. auch dann noch), will ich mehrere Patches zu einem großen zusammenfassen können.
Selektives Anwenden von Patches: Ich will leicht meine/eine Working Copy auf einen Stand bringen können, der den Trunk (oder eine bestimmte Revision) und nur bestimmte Patches enthält. Das ist beispielsweise nötig, um zu prüfen, dass die voneinander unabhängig sind.
Unterstützung bei der Erstellung von Patches: Optimal (aber auch optional und eher nice-to-have) wäre, aus den lokalen Änderungen in der lokalen working copy gegenüber dem Trunk (ggf. zuzüglich einer Auswahl von Patches) einen Patch erstellen zu können – aber nicht mit sämtlichen Änderungen, sondern Auswahlmöglichkeiten bezüglich der Dateien und der einzelnen Änderungen darin. Das geht aber zur Not auch manuell, ggf. mit Nachbearbeiten.

Hat jemand eine Idee, wie man diese Funktionalität am besten umsetzt? Gibt es für so etwas fertige Tools? Ist es vielleicht mit bestimmten Versionsverwaltungssystemen besonders einfach? Git wird ja ständig für alles Mögliche in höchsten Tönen gelobt. Nutzt es vielleicht auch hier? Wenn ja, wie lassen sich obige Anforderungen auf die Begrifflichkeiten von Git (oder einem anderen System) abbilden?

Boost, LEDA und meine wiederhergestellte Ehre

Jens — Tue, 13 Dec 2011 19:43:30 +0000

Neulich, als ich gerade Urlaub hatte, standen bei mir im Büro zwei Studenten, die einen Fehler in meiner Boost-Implementierung entdeckt haben wollten (wie mir danach mein Büromitbewohner berichtete). Zumindest habe ich mich gefreut, dass den Code jemand benutzen wollte. Allerdings haben die beiden sich dann nicht mehr gemeldet. Über Umwege erfuhr ich dann am Wochenende, was der Fehler ist: Es fehlt in leda_graph.hpp eine spitze Klammer:

  template 
  inline
  typename boost::property_traits<
    typename boost::property_map,PropertyTag>::const_type
::value_type
  get(PropertyTag p, const leda::GRAPH& g, const Key& key) {
    return get(get(p, g), key);
  }

Es hat also nicht nur jemand diese Templates auf bisher ungetestete Art und Weise verwendet – das hier knallt schon, wenn man leda_graph.hpp nur einbindet … Dass ich diesen Fehler verursacht haben sollte, erschien mir etwas unplausibel – denn ich habe den Header ja damals benutzt, und mein Programm kompilierte. Also habe ich mir die SVN-Historie angeschaut.

------------------------------------------------------------------------
r36836 | dgregor | 2007-01-29 20:29:06 +0100 (Mo, 29. Jan 2007) | 2 Zeilen

Improvements to LEDA adaptors, from Jens Mueller

@@ -528,11 +884,11 @@
   inline
   typename boost::property_traits<
     typename boost::property_map,PropertyTag>::const_type
-  >::value_type
+::value_type
   get(PropertyTag p, const leda::GRAPH& g, const Key& key) {
     return get(get(p, g), key);
   }

Die ersten Indizien sprachen aber gegen mich: In dem Checkin meines Patches von Douglas Gregor wurde auch das > entfernt. Trotzdem: Irgendwie konnte das doch nicht sein. Also habe ich die Mail herausgesucht, mit der ich den Patch eingereicht habe. Anscheinend habe ich damals den Programmcode im Body der Mail verschickt, statt als Anhang. Klar, mit der Policy von Boost, die Zeilen auf lesbare Länge zu begrenzen, hat das ja auch wunderbar funktioniert. Allerdings wurde dabei offenbar ein > als gequoteter Text interpretiert. Douglas hat dann einfach den Text in eine Datei kopiert und das fehlende > nicht bemerkt. Jens nix schuld, meine Ehre ist wiederhergestellt. Und da es keine automatisierten Tests für die LEDA-Bindings gibt (dafür bräuchte man ja eine LEDA-Installation, und die gab es damals nur gegen Geld), ist das niemandem aufgefallen. Viel irritierender finde ich aber, dass den Fehler vier Jahre lang niemand bemerkt hat

Naja, jedenfalls wurde mir damals angeboten, Maintainer der LEDA-Bindings zu werden. Inzwischen gibt es eine kostenlose Version der LEDA-Bibliothek. Insofern eine gute Gelegenheit, auf das Angebot zurückzukommen. Anscheinend hat sich auch niemand um die Datei gekümmert, und sogar Verbesserungsvorschläge mit fertigen Patches wurden nicht bearbeitet. Vielleicht würde es sich ja lohnen, die wieder hervorzukramen …

Thunderbird-Addons: Optionen

Jens — Sat, 23 Jul 2011 09:02:41 +0000

Heute schauen wir uns, wieder am Beispiel von Quicker Filer 0.5.1, an, wie man in einem Thunderbird-Addon Einstellungen benutzt, die als Preferences persistiert werden.

In der install.rdf heißt es:

chrome://quickerfiler/content/options.xul

Damit wird ein Einstellungsdialog definiert. Standardmäßig wird dieser als Dialogfenster geöffnet. Über die Definition des Content Packages in der chrome.manifest (vgl. dieses Posting) ergibt sich also, dass der Dialog in content/options.xul definiert ist.

Gehen wir das also der Reihe nach durch.

Hier wird ein Stylesheet eingebunden, und zwar ein recht generisches.

Das Fenster ist ein prefwindow, also speziell für Einstellungsdialoge vorgesehen. Es gibt weiterführende Dokumentation, die aber bis auf ein Beispiel und einen Hinweis, wie man so ein Fenster aufruft, keine wesentlichen Infos enthält. Also gehen wir weiter unsere Datei im Detail durch.

Zwei der Attribute sind selbsterklärend: title definiert den Fenstertitel und height setzt die bevorzugte Höhe des Fensters in Pixeln. buttons definiert, welche Schaltflächen angezeigt werden, hier also OK und Abbrechen. Das dürfte üblicherweise eine gute Wahl sein.