Änderungsschritte präsentieren

[Alexander (HH)]

Moin Moin!

Ich brauche mal einen Schubser in die richtige Richtung. Ich suche ein Tool, dass mir (und vor allem meiner Kollegin) möglichst vollautomatisch und möglichst leicht verständlich alle Änderungen an einer Datei zwischen zwei beliebigen Subversion-Revisionen darstellt.

svn diff und dessen HTML generierendes Equivalent in SVN::Web reicht nicht, auch nicht die Diff-Funktion von TortoiseSVN. Jedenfalls nicht für das Verhältnis von geänderten zu unveränderten Zeilen, das hier vorliegt. In der Datei ist quasi kein Stein auf dem anderen geblieben, nachdem ich tonnenweise Spaghetti-Code rausgeworfen und massenhaft Anfänger-Fehler repariert habe.

Es gibt zu jedem einzelnen Schritt Kommentare im Subversion, insgesamt sind bislang so etwa 90 Schritte angefallen, und dabei wird es wohl nicht bleiben. Jeder einzelne Schritt wäre anhand der Commit-Kommentare und ggf. mit svn diff bzw. dessen bunten Nachbauten relativ einfach nachzuvollziehen, aber 90 Schritte kann oder will meine Kollegin nicht im einzelnen nachvollziehen. Ein diff von Anfang bis zum aktuellen Stand bringt gar nichts, da sieht man die einzelnen Änderungsschritte nicht mehr, weil ich wie gesagt fast jede Zeile anfassen mußte.

Eigentlich brauche ich ein Tool, dass aus Commit-Kommentaren und den individuellen diffs eine brauchbare Präsentation baut. Am besten gleich einen Video-Clip à la Maus, der mit Armins ruhiger Stimme alles so einfach erklärt, dass keine Fragen offen bleiben ... ;-) Naja, vielleicht reicht auch etwas Grafik, die zeigt, wie Programmblöcke im Laufe der Zeit wandern und verändert werden. Auf Armin kann ich bei diesem Problem notfalls verzichten.

Oh, und ja, mir ist bewußt, dass ich eine technische Lösung für ein soziales Problem suche.

Alexander

[suit]

Oh, und ja, mir ist bewußt, dass ich eine technische Lösung für ein soziales Problem suche.

Du suchst vermutlich Kompare (Linux/Unix) oder WinMerge (Windows).

[Alexander (HH)]

Moin Moin!

Oh, und ja, mir ist bewußt, dass ich eine technische Lösung für ein soziales Problem suche.

Du suchst vermutlich Kompare (Linux/Unix) oder WinMerge (Windows).

Nö, das reicht leider wie gesagt längst nicht aus.

WinMerge macht wohl exakt das selbe wie die Diff-Funktion von TortoiseSVN, die letztlich TortoiseMerge aufruft. Die Screenshots zeigen auch sehr schön. Beide können hervorragend ZWEI Dateien, bzw. zwei SVN-Revisionen vergleichen, und damit EINEN Schritt dokumentieren. Aber sie können keine Dokumentation/Präsentation von deutlich mehr als einem Arbeitsschritt (eben die 90 Schritte) bauen.

Kompare hat eine etwas innovativere Markierung der Differenzen (auf Kosten des zur Verfügung stehenden Platzes), aber auch Kompare ist auf einen Schritt begrenzt.

Alexander

[suit]

Nö, das reicht leider wie gesagt längst nicht aus.

Dann hab' ich dich falsch verstanden. Schade, dass ich keine weitere Hilfe anbieten kann.

[pgoetz]

Guten Morgen!

[...]
Eigentlich brauche ich ein Tool, dass aus Commit-Kommentaren und den individuellen diffs eine brauchbare Präsentation baut. Am besten gleich einen Video-Clip à la Maus, der mit Armins ruhiger Stimme alles so einfach erklärt, dass keine Fragen offen bleiben ... ;-) Naja, vielleicht reicht auch etwas Grafik, die zeigt, wie Programmblöcke im Laufe der Zeit wandern und verändert werden. Auf Armin kann ich bei diesem Problem notfalls verzichten.

Also ich kenne kein Werkzeug, was so etwas leisten würde. Aber ich denke, man könnte sich etwas ähnliches bauen, indem man einen diff immer zwischen zwei aufeinanderfolgenden Versionen des SVN Repository macht, und diese dann als Grafiken hintereinanderschachtelt. Armins ruhige Stimme musst Du aber dann selbst dazusynchronisieren. :)
Als Batch-Datei müsste das allein mit Subversion-, Datei- und Grafikbefehlen (hier muss man schauen, ob die grafischen Diff-Tools eine Shell-Schnittstelle bieten) gehen.
Ist übrigens ein spannendes Problem, dessen Fortschritt mich interessiert.

Schöne Grüße,

Peter

[Alexander (HH)]

Moin Moin!

Also ich kenne kein Werkzeug, was so etwas leisten würde. Aber ich denke, man könnte sich etwas ähnliches bauen, indem man einen diff immer zwischen zwei aufeinanderfolgenden Versionen des SVN Repository macht, und diese dann als Grafiken hintereinanderschachtelt.

Das war auch meine Grundidee, das scheitert aber an der zur Verfügung stehenden Zeit und am Platzbedarf:

* Im Moment ist einfach keine Zeit da, so etwas "nebenher" zu bauen.
* Zeilenlängen von deutlich mehr als 100 Zeichen, und eine Dateigröße von rund 3000 Zeilen. Manche eigentlich trivialen Schritte streuen wie Schrot im Code, das diff wird also entweder vollkommen unleserlich oder groß wie ein Werbeplakat.

Armins ruhige Stimme musst Du aber dann selbst dazusynchronisieren. :)

Hehehe ...

Als Batch-Datei müsste das allein mit Subversion-, Datei- und Grafikbefehlen (hier muss man schauen, ob die grafischen Diff-Tools eine Shell-Schnittstelle bieten) gehen.

Ich hab ja auch ein Linux zur Verfügung, da könnte man mit ImageMagick & Co. auf der Kommandozeile schon eine ganze Menge anstellen. SVN::Web bringt auch schon Tools mit, um Diffs aus dem SVN zu ziehen und sie ansehnlich einzufärben (via HTML/CSS).

Wahrscheinlich könnte man mit einer passenden Aufbereitung der Rohdaten à la SVN::Web und mit einer Flash- oder AJAX-Anwendung schon eine ganze Menge erreichen.

Ich hab noch nicht mal eine konkrete Vorstellung, wie ich die Schritte präsentieren will. Mir spuken ein paar technisch-wissenschaftliche Flash-Präsentationen im Kopf rum (z.B. Zoom rein von Mensch bis zum Quark, Zoom raus vom Mensch bis zum beobachtbaren Universum, oder auch dieser Größenvergleich), und auch die Idee, das Wandern von Code in den Arbeitsschritten zu animieren.

Beispiele:

* Die Zeilen 1500 bis 1540 beschließen, dass sie besser eine eigene Funktion werden, ziehen sich seitlich aus dem Code raus, ersetzen sich durch einen Aufruf der neuen Funktion, und verpassen sich selbst einen entsprechenden Funktions-Header. Dann wandern sie mit ihrem neuen Funktionsheader an eine andere Stelle im Code, weiter oben. (An diesem Punkt haben wir das Niveau der Maus erreicht.) Das entspricht in diesem Fall nämlich sehr genau meiner Arbeitsweise. Und anhand des SVN-Repositories und der Code-Struktur müßte man sich die Informationen tatsächlich aus den vorhandenen Daten rausziehen können.

* Analog das (leider gelegentlich notwendige) Umbenennen von Variablen und Funktionen. Aus der 10.000-Fuß-Perspektive sieht man ein paar "zappelnde" Variablen, die alle synchron von foobar zu Foo_Bar mutieren. Vielleicht ist das mit Zoom-Effekten zu illustrieren: Angefangen bei der Deklaration der Variable rauszoomen auf den gesamten betroffenen Code. Auch das sollte mit den vorhandenen Daten "findbar" sein.

* Toter Code, unbenutzte Variablen verrotten oder faden zur Hintergrundfarbe.

Soweit der Spieltrieb. Etwas nüchterner ohne die Animationen durch ein paar Pfeile und Klammern für wandernden Code, durch Durchstreichen und neuen Namen darüber / daneben schreiben für Umbenenn-Aktionen, durch einfachees Durchstreichen / Ausgrauen für Löschaktionen. Daneben / darüber der Commit-Kommentar, und eine einfacher Weiterblättern-Funktion.

Ist übrigens ein spannendes Problem, dessen Fortschritt mich interessiert.

Ja, aber im Moment sieht es leider aus wie eine Sackgasse, wie so viele Anläufe, soziale Probleme technisch zu lösen. Das Problem ist doch, wie ich die einzelnen Schritte so vorkauen kann, dass sie ohne viel Widerstand im Verstand meiner Kollegin ankommen. Und das dahinter liegende Grundproblem ist, dass meine Kollegin sich die einzelnen Arbeitsschritte nicht selbst anhand von Commit-Kommentar und (grafisch aufbereitetem) Diff erarbeiten kann oder will.

Alexander

[pgoetz]

Servus,

[...]
Beispiele:
[...]

Deine Beispiele zeigen, dass man das Problem leider mit einem einfachen Diff und einer grafischen Aufbereitung nicht lösen kann, denn da fehlt noch ein bisschen Logik. Man müsste also anhand der Diff-Muster erkennen, welche Art von Änderung durchgeführt wurde. Ich glaube, das ist sehr schwer bis unmöglich, außer, man hält im Hintergrund der Analyse eine ähnlich intelligente Quellcoderepräsentation vor wie Eclipse das in seiner IDE macht (und z.B. für das Refactoring nutzt). Und selbst dann ist es noch eine immense Aufgabe, die entsprechenden Schritte korrekt und ansprechend darzustellen (auch ohne Zoom, Fading und die anderen grafischen Spielereien).
Ich bleib dabei, ein sehr spannendes Projekt, ergänze aber meine Einschätzung, dass es vermutlich nicht umsetzbar ist. :)

Die Kollegin wird in den sauren Apfel beißen müssen. ;) Hat sie das zu refaktorisierende Stück Quellcode (3000 Zeilen sind kein Spaß!) verbrochen? Dann hat sie auch das Verstehen "zu Fuß" verdient.

Schöne Grüße,

Peter

[Alexander (HH)]

Moin Moin!

Deine Beispiele zeigen, dass man das Problem leider mit einem einfachen Diff und einer grafischen Aufbereitung nicht lösen kann, denn da fehlt noch ein bisschen Logik.

Richtig.

Man müsste also anhand der Diff-Muster erkennen, welche Art von Änderung durchgeführt wurde. Ich glaube, das ist sehr schwer bis unmöglich, außer, man hält im Hintergrund der Analyse eine ähnlich intelligente Quellcoderepräsentation vor wie Eclipse das in seiner IDE macht (und z.B. für das Refactoring nutzt).

Genau. Obwohl man ab einem gewissen, sehr frühen Punkt (nach Schritt 5 oder so) davon ausgehen kann, dass der Code wenigstens sauber eingerückt ist und man daraus die Strukturen ableiten kann, ohne wirklich parsen zu müssen.

Und selbst dann ist es noch eine immense Aufgabe, die entsprechenden Schritte korrekt und ansprechend darzustellen (auch ohne Zoom, Fading und die anderen grafischen Spielereien).

Richtig. Deswegen suche ich ja was Fertiges. Auf den Spielkram kann ich locker verzichten.

Ich bleib dabei, ein sehr spannendes Projekt, ergänze aber meine Einschätzung, dass es vermutlich nicht umsetzbar ist. :)

Nicht ohne einige Einschränkungen, richtig. Das wäre vom Umfang her sicherlich genügend Stoff für die eine oder andere Diplomarbeit.

Die Kollegin wird in den sauren Apfel beißen müssen. ;)

Ja. Sagst Du ihr es? ;-)

Hat sie das zu refaktorisierende Stück Quellcode (3000 Zeilen sind kein Spaß!) verbrochen? Dann hat sie auch das Verstehen "zu Fuß" verdient.

Nee, der ursprüngliche Pfuscher hat "das Unternehmen auf eigenen Wunsch verlassen", dem kann ich nicht mehr auf die Füße treten (lassen).

Die 3.000 Zeilen in der einen Datei sind ja auch nur der Anfang. Das ganze Projekt düfte auf so etwa 300.000 Zeilen +/- 20% kommen, alle in ähnlicher Qualität[1], mit viel Copy&Paste, Cargo Cult und unausgegorenen Basteleien. Was man eben so nach 10 Jahren Frickelei durch einen Amateur an einer weitere 20 Jahre durch andere Amateure zusammengefrickelten Betriebsumgebung erwarten kann.

Wir beide sind jetzt diejenigen Deppen, die den Scheiß am Leben halten und gleichzeitig aufräumen müssen.

Alexander

[1] Wer jetzt den Spruch "Qualität kommt von Quälen" bringt, wird geteert und gefedert!

[pgoetz]

Servus!

[...]
Ja. Sagst Du ihr es? ;-)

Dazu müsste ich das Gehalt von Ryan Bingham aus "Up in the Air" bekommen. :)
Aber ich könnte sie trösten, weil ich ein ähnliches Stück Software (nicht in dem Umfang, aber zumindest in der Qualität) auch schon bei einem Arbeitgeber zu bearbeiten hatte. Ich habe dann auch das Unternehmen auf eigenen Wunsch verlassen. ;)
Ich wünsche Euch viel Erfolg! Auch wenn ich nichts Konstruktives zur Lösung Deines Problems beigetragen habe.

Schöne Grüße,

Peter