So, jetzt erstmal die versprochene Antwort:
cloidnerux hat geschrieben:
Wir erleben hier ein sehr typisches Problem: Mangelnde Kommunikation!
Ich bin verantwortlich für die hashklasse, werde also selber dort Änderungen einführen und Fehler korrigieren.
Wenn du etwas änderst im Trunk und ich davon nichts weiß, kann ich sie auch nicht übernehmen.
Im gegenteil, wie jetzt geschehen habe ich meine neue Version vom branch nach Trunk kopiert.
Ich habe aber in der aktuellen Version alle Fehler beseitigt und die Quellen im Branch sind neu, die habe ich erst vorhin hochgeladen.
Ich Denke, wir sollten uns über einem kürzeren Kommunikationskanal verständigen, sprich ICQ/Skype sonstige Chats und Videokonferenzen.
cloidnerux hat geschrieben:
SVN hat extra einen Branch und Trunk. Man soll immer eine Stabile Version im Trunk und alles Instabile und "Work in progress" im branch lassen, das alle die Möglichkeit haben immer eine Funktionierende Version aus dem trunk zu ziehen.
Im gegenteil: du schadest wenn du im Trunk arbeitest! Dadurch das die Dateien im Trunk neuer sind, wird jeder der in seinem Branch weitermachen will auf alte Dateien stoßen, die nur wieder Probleme hervorrufen.
Ich gebe dir teilweise Recht und teilweise auch nicht. Das mit der Kommunikation stimmt, ich habe nicht darauf hingewiesen, dass ich beim Integrieren der Hashklasse Fehler fixen musste.
Achtung hier folgt mein persönliches Verständnis/Meinung zum Thema SVN nach Konsum der vorherrschender Meinung hier im Dedupe Projekt und den SVN Richtlinien: Sobald ein Feature fertig entwickelt ist und nach Trunk wandert, finden kleiner Korrekturen und Verbesserungen, wie z. B. das Hinzufügen einer Funktion in Trunk statt, vor allem wenn es sich um Fixes handelt, die in anderen Teilen des Projektes benötigt werden. Wenn jemand dann in seinem Branch weiterentwickeln will, muss er selber darauf achten, das Trunk und Branch nicht zu weit auseinanderdriften und inkompatibel werden, sprich er muss Trunk regelmäßig auf den Branch mergen, damit er mit dem aktuellen Stand arbeiten kann, weil sich zum Beispiel Klasseninterfaces verändert haben.
Damit zum aktuellen "Problemfall": Die Entwicklung der Hashklasse war vor Monaten abgeschlossen und dementsprechend hast du sie völlig korrekt nach Trunk kopiert. Damit ist der Branch eigentlich tot, er hat seinen Zweck erfüllt. Da Hash jetzt im Trunk liegt, kann jeder daran arbeiten und Verbesserungen vornehmen. Mir sind nach der Integration einige kleine Fehler im Codingstandard aufgefallen und habe angefangen sie zu korrigieren, lediglich optische Verbesserungen, keine große Sache. Einige Zeit später habe ich festgestellt, das für die Hashklasse eine Zusatz nötig war, damit sie sich ordentlich mit den anderen Modulen verwenden lässt und habe dich in der Hinsicht um Rat gefragt( Du erinnerst dich bestimmt an unseren PN Austausch zu dem Thema ). Du hast das Problem sehr schnell angegangen und die entsprechende Funktion hinzugefügt und zwar auf der Grundlage des Dateistandes in deinem Branch. Vor zwei Tagen habe ich jetzt die Zeit gefunden, deine Zusatzfunktion anzusehen und sie von deinem Branch nach Trunk kopiert. Dabei habe ich festgestellt, dass die Dateien neben ein paar kleinen vertippern und kleinen Fehlern auch noch auf das veraltete Interface von Filesearch zurückgreift. Also habe ich die Sachen so gefixt, das der Code kompiliert. Als Folge davon sind jetzt die Verbesserungen im Codestandard verloren, was ich jetzt nicht so sonderlich schlimm finde und ich hatte eine Stunde Sucharbeit, um den Code überhaupt zum kompilieren zu bekommen. Beim herumspielen habe ich den vorhin erwähnten Bug entdeckt und dich auf den Bug hingewiesen. Um dir die Fehlersuche zu erleichtern, habe ich diesen Stand nach Trunk hochgeladen, da Trunk der Hauptzweig ist und ich derzeit ausschließlich dort arbeite. Solange die eigene Arbeit nicht die Arbeit der anderen stört, z.B. weil es riesige Umbauten gibt und laufend der Build bricht, ist das auch vollig legitim und normal, zumal wir noch nicht einmal so weit sind, eine Alpha zu veröffentlichen. Stablile Releaseversionen wandern ohnehin nach Tag, Trunk verändert sich also laufend. Darauf hast du den Fehler gefixt und zwar wieder in dem Hash Branch und das ganze dann ohne weiter Nachfrage nach Trunk kopiert. Damit sind alle schon gefixten Fehler wieder da und ich musste den Code nochmal anpassen.
Ich finde folgenden zwei Punkte dabei nicht in Ordnung:
Zum einen, dass du Fehlerkorrekturen in einen Branch commitest, der noch nie mit Trunk gemerged wurde, bzw. nicht auf dem aktuellen Stand ist und eigentlich schon seit bestimmt schon fast 6 Monaten tot ist.
Zum anderen finde ich es falsch, Code nach Trunk zu kopieren, der noch nicht einmal durch den eigenen Compiler gelaufen ist und folglich eine Menge Fehler enthalten kann und sie wie aktuell zu sehen, auch enthalten hat.
Ich mache darum den Vorschlag, solche Fehler entweder in Trunk direkt zu fixen, bzw. sich daraus eine aktuelle Arbeitskopie zu erstellen, den Fehler da zu fixen, das ganze testweise kompilieren zu lassen und dann zu commiten. Die andere Lösung wäre es, Trunk auf den eigenen Branch zu mergen und dann dort die Fehler zu fixen. Wenn man selber nicht kompilieren kann, können auf der Grundlage die anderen Testen und Rückmeldung geben. Wenn alles in Ordung ist, kann man das ganze nach Trunk reintegrieren. Diese Vorgehen kostet nicht viel Zeit, ist einfach und dadurch hätten wir allen Problemen aus dem Weg gehen können.
Bitte werte das nicht als persönlichen Angriff, ich hoffe der Ton ist sachlich und nicht beleidigend, das war nie meine Absicht.
So jetzt wieder zu dem Bug
cloidnerux hat geschrieben:
Die Lösung dieses Problems ist einfach: hash.GetHash();
Als erstes: Trunk enthält momentan die aktuellste Version. Der Code kompiliert, allerdings erhalte ich jetzt statt eines bad_alloc Fehlers bei sehr großen Dateien ein Segmentation fault. Kleine Dateien werden problemlos gehasht, ab 6 GB aufwärts Segmentation fault. Da ich vier GB Ram und 2 GB Swap habe, vermute ich mal, das der Ram noch immer überläuft.