PureBoard

Kannst du mir mal bitte ein Beispiel posten?
So wie ich das verstanden habe, nämlich so:



bzw. so:



geht es bei mir.

Habe mir eben Dein Tool gegönnt. schaut gut aus
Dabei ist mir aufgefallen, dass die DB reichlich "dick" bleibt, wenn man
sehr viele Daten rauslöscht, bzw. einen alten Stand wiederherstellt.

Für Sqlite gibt es das
http://sqlite.org/lang_vacuum.html

und für PostGRES das
http://www.postgresql.org/docs/7.4/stat ... acuum.html


Ich hatte mal einen Verzeichnisbaum in hv eingelesen (SpecialTasks)
und dann angefangen einzlne Dateien wegzukicken.
Das rekursive Löschen mit Ordnerangabe könnte das manuelle
Aufräumen schneller machen. Jede Datei einzeln anzuklicken ist
dann doch sehr mühsam.

bobobo hat geschrieben:Habe mir eben Dein Tool gegönnt. schaut gut aus

Danke

bobobo hat geschrieben:Dabei ist mir aufgefallen, dass die DB reichlich "dick" bleibt, wenn man
sehr viele Daten rauslöscht, bzw. einen alten Stand wiederherstellt.

Für Sqlite gibt es das
http://sqlite.org/lang_vacuum.html

und für PostGRES das
http://www.postgresql.org/docs/7.4/stat ... acuum.html

Das sollte via "Rebuild Database" bei den Special Tasks gehen.
Aber reichlich "dick" finde ich etwas übertrieben.
Immerhin wird das ja alles komprimiert.

bobobo hat geschrieben:Ich hatte mal einen Verzeichnisbaum in hv eingelesen (SpecialTasks)
und dann angefangen einzlne Dateien wegzukicken.
Das rekursive Löschen mit Ordnerangabe könnte das manuelle
Aufräumen schneller machen. Jede Datei einzeln anzuklicken ist
dann doch sehr mühsam.

Jetzt bin ich aber überrascht.
Ich hätte schwören können, dass ich das schon mal integriert hatte.
Tatsächlich etwas, das noch rein sollte.

"dick" bezog sich auf gespeicherte drei Quellcodes im Gegensatz zu ca 320 codes (und eben nicht die kleinsten).
Das sieht man der Db dann eben schon an (Faktor hundert)
Aber wenn die Specialtasks sowas bereinigen können ist es ja auch ok.

Ordnerweise löschen ginge nur wenn man Ordnerweise "ignoriert" (Was übrigens ganz schön lange dauert, weil da vermuitlich jeder einzelne Satz ind der DB angefasst und bei Bedarf gelöscht wird. Hier könnte eine Transaction (falls das hier angebracht ist) die
Sache beschleunigen).

bobobo hat geschrieben:"Ordnerweise löschen ginge nur wenn man Ordnerweise "ignoriert" (Was übrigens ganz schön lange dauert, weil da vermuitlich jeder einzelne Satz ind der DB angefasst und bei Bedarf gelöscht wird. Hier könnte eine Transaction (falls das hier angebracht ist) die
Sache beschleunigen).

Stimmt, da sollte man noch an der Performance schrauben können.
Falls ich mal irgendwann wieder die Zeit zum Programmieren finde, werde ich mir diese beiden Punkte mal anschauen.

Aber eigentlich warte ich noch auf Rückmeldung von dige...

Ups, entschuldige bitte. Ich hatte den HistoryViewer geupdated und dabei irgendwie
meine DB kaputt gemacht. Daher konnte ich keine Tests mehr machen.
Den Fehler kann ich mit Version v2.15 jetzt nicht mehr reproduzieren.
Sorry wegen irgendwelcher Umstände...

Neues Update: V2.16

Änderungen:

• Löschen von History-Ordnern
• Splitter kann komplett nach links verschoben werden (für kleine Monitore/Auflösungen)
• Ein wenig Performancegewinn beim Löschen/Ignorieren, aber nicht wirklich viel (s.u.)

Updaten unter Windows:
Einfach History Viewer aufrufen und auf das ? und "Check for update" auswählen.

Updaten unter Linux:
zip herunter laden und das Original überschreiben.
(von 2.15 auf 2.16 reicht die hv-Datei)

Zu dem leichten Performancegewinn beim Löschen/Ignorieren von vielen Dateien:
Unter sqlite hätte ich das in einen SQL-Aufruf packen können, was dann natürlich rasend schnell gewesen wäre.
Aber unter postgresql und dem dort vorhandenen Feature der "shared files" ginge das nicht.
Bevor ich dann zwei versch. Routinen mache, mache ich lieber eine langsamere, die für beide funktioniert.

So oft werden ja wohl kaum ganze History-Ordner gelöscht.

Aber ich habe dem Ganzen noch einen Fortschrittsbalken gegönnt, damit man wenigstens sieht, was auf einen zukommt


Windows-Version
Linux-Version

V2.17

Alles weitere hier

Update V2.18

1. Added: Any individual history is deletable now. (Changes will be integrated in the following history)
2. Changed: Select Archive Window now resizable
3. Changed: Added a Version ComboBox to Archive-Window
4. Fixed: When enabled "store histories directly on saving" no more backups have been created

Windows Version
Linux Version

auch für den genialen Updater!