proggen.org

[edit] Ausgeschnitten als Antwort aus diesem Thread: http://www.proggen.org/forum/viewtopic. ... 628#p25628

Juhu!
Es funktioniert!

Gratulation zu deiner tollen Arbeit, Bebu
Ich hab damit mein Verzeichnis bearbeitet, und es scheint funktioniert zu haben. Ganz viel Kudos!

Ich werde demnächst das Debian-Paket updaten.

Übrigens kann man hier glaube ich durchaus ne Versionsnummer springen lassen. 0.1 anyone? Chef (Xin)?

Die Grundfunktionalität steht, jetzt sind wohl unsere Grafischen-Oberflächen-bauer am Zug. Dani93, gibts ne geschätzte Prozentzahl des Grades der Fertigstellung? Xin?

@Bebu: ich glaube langweilig wird dir auch nicht, du wirst wahrscheinlich am CLI-Interface herumbasteln? Da waren noch einige "Unimplemented". Du kannst mich wie immer als Tester missbrauchen.

Was noch cool wäre (als nicht ganz so optionale Features):
* Erkennung von Symbolischen Links
* (???) Erkennung von Hardlinks (geht das überhaupt mit Boost.Filesystem??)

Was noch cool wäre als optionale Features mit niedriger Priorität:
* Linken statt Löschen
* Datenbankupdate/Erstellung ohne hashen (aka nur Größe/Name erfassen)

fat-lobyte hat geschrieben:Dani93, gibts ne geschätzte Prozentzahl des Grades der Fertigstellung?

Das ist sehr schwer einzuschätzen, da wir die verfügbaren Features auch nicht exakt abgesteckt haben. Rein optisch ist wahrscheinlich der größte Teil erledigt, viel wird jetzt noch über das allgemeine Interface laufen, das für alle GUIs gleich ist. Die echte Oberfläche übernimmt nur mehr das Event-Handling und ruft dann die entsprechende Interface-Methode auf.

fat-lobyte hat geschrieben:Übrigens kann man hier glaube ich durchaus ne Versionsnummer springen lassen. 0.1 anyone? Chef (Xin)?

Eine Versionsnummer sollte es eig immer haben.
Im Idealfall eine 0.1.<repository-revision>

fat-lobyte hat geschrieben:Die Grundfunktionalität steht, jetzt sind wohl unsere Grafischen-Oberflächen-bauer am Zug. Dani93, gibts ne geschätzte Prozentzahl des Grades der Fertigstellung? Xin?

10%.

Heute abend habe ich noch zwei andere Meetings, morgen fällt das Kino gerade aus. Ich kann dedupe auf dem aktuelleren Linux kompilieren und ausführen - das ist ja auch schonmal was. Es bestehen also Chancen.

fat-lobyte hat geschrieben: Was noch cool wäre als optionale Features mit niedriger Priorität:
* Linken statt Löschen

Die Idee ist so billig, dass sie wieder genial ist. ^^

dani93 hat geschrieben:viel wird jetzt noch über das allgemeine Interface laufen, das für alle GUIs gleich ist. Die echte Oberfläche übernimmt nur mehr das Event-Handling und ruft dann die entsprechende Interface-Methode auf.

Das Interface ist zumindest Funktionell soweit nutzbar, wenn ich richtig verstehe? Willst du damit zum Ausdruck bringen, dass da nicht mehr viel zu machen ist?

Xin hat geschrieben:Eine Versionsnummer sollte es eig immer haben.
Im Idealfall eine 0.1.<repository-revision>

Hm, ich denke das gilt nur für Debian Pakete (im Format 0.1~svnXXX). Damit meinte ich so ne Art "developer Release", die dann tatsächlich "0.1" heißt. Die hätte (zumindest in Git) einen Tag, normale Revisions würde man wohl nur über die Revision-Nummer ansprechen?

Xin hat geschrieben:

fat-lobyte hat geschrieben:Was noch cool wäre als optionale Features mit niedriger Priorität:
* Linken statt Löschen

Die Idee ist so billig, dass sie wieder genial ist. ^^

War auch nicht meine. Ist erstens schon gefallen (dani93 glaub ich?), zweitens können das vorhandene Deduplikationsprogramme auch schon.

Xin hat geschrieben: 10%.

Heute abend habe ich noch zwei andere Meetings, morgen fällt das Kino gerade aus. Ich kann dedupe auf dem aktuelleren Linux kompilieren und ausführen - das ist ja auch schonmal was. Es bestehen also Chancen.

Nur keinen Stress. Ich denke, wenn das CLI-Interface gut funktioniert und die Qt-Oberfläche einigermaßen sind wir schon auf der sicheren Seite. Es gibt noch einiges am Rest zu feilen, bis man einen Release machen könnte, also hast du für Ncurses noch genug Zeit.

Wir verlassen hier zwar gerade das eigentlich Thema diese Threads, aber so sehen mein Planungen im Moment aus:
-Einfache Deduplizierfunktionen ohne Datenbank nach Dateiname, Größe, Änderungsdatum
-Keep File Funktionen fertigstellen
-Mulithreading implementieren
-Baustelle für Nachrichtenausgabe des Kernels und Verbose schließen
-Fortschrittsausgabe
-Option um leere Ordner automatisch löschen zu lassen
-Duplikate als Textdatei ausgeben und mit Nutzerentscheidung versehen wieder einlesen, als Alternative zum jetzigen UI
-FREEZE -> 1.Stabile Version releasen
Dann kann man sich an solche Features wagen, wie von fat-lobyte gewünscht und sie für den nächsten Release einbauen

Ich möchte gerne in absehbarer Zeit einen stabilen Release herausgeben können.

Es wäre außerdem super, wenn ihr solche Featurerequests auch in den Bugtracker übertragen könntet, sonst gehen sie hier im Forum verloren. Am besten unter Kernelmodul mit dem Titel Featurerequest.

@fat-lobyte: Softlinks beherrscht boost::filesystem, aber ob dass das auch auf Windows klappt, glaube ich nicht so ganz. Es wäre auf jeden fall machbar, wenn wir nur von Linuxunterstützung sprechen.

Bebu hat geschrieben:Wir verlassen hier zwar gerade das eigentlich Thema diese Threads

Ich hab jetzt ein bisschen herumgeschoben. Hoffentlich nicht zu schlimm.

Bebu hat geschrieben:, aber so sehen mein Planungen im Moment aus:
-Einfache Deduplizierfunktionen ohne Datenbank nach Dateiname, Größe, Änderungsdatum
-Keep File Funktionen fertigstellen
-Mulithreading implementieren
-Baustelle für Nachrichtenausgabe des Kernels und Verbose schließen
-Fortschrittsausgabe
-Option um leere Ordner automatisch löschen zu lassen
-Duplikate als Textdatei ausgeben und mit Nutzerentscheidung versehen wieder einlesen, als Alternative zum jetzigen UI

Sieht nach nem Plan aus! Aber Baustellen immer zuerst schließen, also das müsste ganz nach oben in die Prioritätsliste.

Dann kann man sich an solche Features wagen, wie von fat-lobyte gewünscht und sie für den nächsten Release einbauen

Gewünscht ist übertrieben, eher vorgeschlagen Aber ich werde dich mal mit Bugs zumüllen.

Es wäre außerdem super, wenn ihr solche Featurerequests auch in den Bugtracker übertragen könntet, sonst gehen sie hier im Forum verloren. Am besten unter Kernelmodul mit dem Titel Featurerequest.

Gute Idee. Du kannst dir deine Todo-Liste auch gern selbst als Bugs eintragen, natürlich nur wenns dir bequem ist.

Bebu hat geschrieben:Ich möchte gerne in absehbarer Zeit einen stabilen Release herausgeben können.

Bebu hat geschrieben:-FREEZE -> 1.Stabile Version releasen

Da bin ich auch schwer dafür. Software, die keiner sieht ist nicht nutzbare Software. Ein Release ist wichtig, um das Programm einmal in Form zu bringen und Hübsch anzuziehen, und es dann auch verteilen kann. Da sollten wir uns übrigens auf vernünftige, und in Absehbarerer Zeit machbare Release-Goals einigen.

Bebu hat geschrieben:@fat-lobyte: Softlinks beherrscht boost::filesystem, aber ob dass das auch auf Windows klappt, glaube ich nicht so ganz. Es wäre auf jeden fall machbar, wenn wir nur von Linuxunterstützung sprechen.

Also NTFS kann sowohl Soft- als auch Hardlinks (was nicht viele Wissen). Also wenn Boost.Filesystem das unterstützt, müsste es gut aussehen.

Ich habe mir gerade die Referenz angesehen. Filesystem beherrscht sowohl Soft- als auch Hardlinks. Allerdings ist der Hinweis enthalten, dass das wohl nicht auf allen Dateisystemen funktioniert. Das müssen wir dann im einzelnen Ausprobieren.

fat-lobyte hat geschrieben:

dani93 hat geschrieben:viel wird jetzt noch über das allgemeine Interface laufen, das für alle GUIs gleich ist. Die echte Oberfläche übernimmt nur mehr das Event-Handling und ruft dann die entsprechende Interface-Methode auf.

Das Interface ist zumindest Funktionell soweit nutzbar, wenn ich richtig verstehe? Willst du damit zum Ausdruck bringen, dass da nicht mehr viel zu machen ist?

Ja, ich sehe da nicht mehr viel Aufwand dahinter.

fat-lobyte hat geschrieben:

Xin hat geschrieben:

fat-lobyte hat geschrieben:Was noch cool wäre als optionale Features mit niedriger Priorität:
* Linken statt Löschen

Die Idee ist so billig, dass sie wieder genial ist. ^^

War auch nicht meine. Ist erstens schon gefallen (dani93 glaub ich?), zweitens können das vorhandene Deduplikationsprogramme auch schon.

Ich glaube du meinst das:
http://www.proggen.org/forum/viewtopic. ... =70#p25383
Um das richtig zu stellen ^^

Ich habe ein kleines "Zuckerl" zum testen. Dedupe kann jetzt Dateinamen zur Duplikatunterscheidung nutzen. Die Option "find-filename-duplicates" ist sowohl auf die Datenbank, als auch auf normale Ordner anwendbar, je nachdem, ob man einen Ordner angibt oder nicht. Wer will kann ein bisschen damit spielen, ruhig auch mit recursiv und Datenbankupdateunterdrückung. Falls was nicht klappt, bitte um Feedback.
Jetzt fehlen noch Duplikate nach Dateigröße, Änderungsdatum und nach Hash für direkt angegebene Pfade. Das sollte aber jetzt wieder schneller gehen, die Vorarbeit ist jetzt gemacht.

Bebu hat geschrieben:-Einfache Deduplizierfunktionen ohne Datenbank nach Dateiname, Größe, Änderungsdatum

DONE. Dedupe kann jetzt nach Hash, gleichen Dateinamen, Änderungsdatum und Dateigröße Duplikate aufspüren. Das ganze geht entweder über den Inhalt der Datenbank, oder per Direktangabe von Verzeichnissen auf der Kommandozeile. Happy Testing.