Danke für den Hinweis, den Fehler hätte ich vermutlich ewig gesucht^^ Ist seit Revision 181 gefixt.Bemerkung am Rande: fileinfo.cpp zeile 28: Das "==" sollte vlt gegen ein "=" ausgetauscht werden. Ebenso in zeile 39
Ich teile diesen Standpunkt. Code der in Trunk liegt, darf von allen Entwicklern, die Repozugang haben angepasst und verbessert werden. Kleine Fehlerkorrekturen verändern nicht die grundlegende Funktionalität, oder die eigentliche Arbeitsweise. Wenn man dagegen plant, das Interface eines anderen zu verändern, dann sollte man das nicht still und heimlich tun. Die Branches anderer sollten aber tatsächlich tabu sein, außer man hat die Ausdrückliche ErlaubnisEs müssen nicht mehrere Leute gleichzeitig an einer Sache arbeiten. Das geht, aber das muss organisiert sein.
Es muss aber möglich sein, dass mehrere Leute zu unterschiedlichen Zeiten an einer Sache arbeiten können.
Jeder muss aber in der Lage sein, den vorhandenen Code zu überarbeiten, ohne ihn neu zu schreiben zu müssen. Daher muss jeder Code so gehalten sein, dass ein anderer ihn modifizieren kann.
Hier muss ich entgegenhalten, das es zu diesem Zeitpunkt nur ein einziges Interface gab und das hat Xin als Schnittstelle zu den GUIs konzipiert. Irgendwann hieß es: "Fangt mal an, aber rechnet nicht damit, das es so bleibt, wie ihr es euch gedacht habt." Dann hatten wir eine Menge Code, der in verschiedenen Branches herumgeflogen ist. Da von anderer Seite nicht viel kam, habe ich halt angefangen Klassen zu schreiben und Interfaces zu definieren. Dabei entstand die Idee zu FileInfo, um ein Fixes Austauschobjekt zwischen allen Teilmodulen zu schaffen. Ich sah aber keinen Sinn darin, in einem Informationsobjekt eine Hashklasse zu halten, wenn der Hashwert alleine ausreicht. Auf dieser Uberlegung aufbauend, bin ich bei dem Konzept gelandet, das ich aktuell verfolge.Und hier sind wir wider bei der Projektplanung: Ich baute eine Generische Klasse ohne weitere nicht-Standard Abhängigkeiten und dem Ziel, das die Klasse nur Daten hashte und sonst nix. Und dann hat man mich gebeten, einen Teil der Funktionalität, die egt nicht in der Hashklasse liegen sollte, eben dort zu Implementieren: Das Abarbeiten eines FileInfo-Streams. Nun muss ich in einer "generischen" in einer egt "statischen" Memberfunktion mich mit dem Laden und Auswerten von Daten herumschlagen und das ist meiner Meinung nach schwachsinnig, auch weil bebu das Interface zwischenzeitlich wieder geändert hat...
Was die Interfaces betrifft, unterliegen diese natürlich einem ständigen Wandel, solange die Grundfunktionalitäten noch nicht stehen. Bei Beginn der Arbeiten an der Datenhaltung ist mir aufgefallen, das FileInfo zu überladen ist und viel Leichtgewichtiger ausfallen kann. Ich hatte einfach Sachen eingebaut, die vielleicht irgendwann mal gebraucht werden könnten. Vieles davon ist wieder herausgeflogen. Dann ist mir aufgefallen, das sich meine Sachen in allen möglichen Namespaces verlieren und man Dinge die man ständig braucht kaum auf Anhieb findet. Das werde ich als nächstes Verbessern und vereinfachen. Aber solche Dinge werden ständig auftreten. Wenn man darüber spricht, hat auch jeder ausreichend Zeit sich darauf einzustellen und seine Funktionen an das neue Interface anzupassen. Da ich aber über einen langen Zeitraum nur Konflikte in meinem eigenen Code lösen musste, ist die Kommunikation an der Stelle etwas kurz geraten.