PureBoard

HeX0R hat geschrieben:Das ist wahrscheinlich der Knackpunkt.
Bevor er eine neue History hinten anhängen kann, muss er ja erst alle deine Versionen durchlaufen und restaurieren.

Wie wäre es denn, wenn du die letzte Version immer noch mal extra speicherst? Dann muss man nur nochmal alle vorherigen Versionen durchlaufen, wenn man einen oder mehrere Schritte zurück gehen möchte. So macht es doch z.B. auch SVN.

ts-soft hat geschrieben:25 Versionen.

Ah, o.k., ich hatte schon weit mehr als 100 befürchtet.

ts-soft hat geschrieben: Jetzt wo ich den HistorieViewer offen habe, sticht mir noch eine Unschönheit ins Auge:
Dateiname, Version und das andere ist wohl das Datum, kann ich Aufgrund der Schrift
nicht lesen. Willste nen Screenshot?

Im Moment nicht, in der V2.13 ist eh noch ein Bug in den beiden Templates, eigentlich sollte die Darstellung ein wenig anders aussehen.
Wenn ich die V2.14 release (in den nächsten paar Tagen, schätze ich), wird mich das eher interessieren (falls die Darstellung dann immernoch verknisknaddelt ist).

NicTheQuick hat geschrieben:Wie wäre es denn, wenn du die letzte Version immer noch mal extra speicherst? Dann muss man nur nochmal alle vorherigen Versionen durchlaufen, wenn man einen oder mehrere Schritte zurück gehen möchte. So macht es doch z.B. auch SVN.

Naja, die Ursprungsidee war das ganze sehr platzsparend zu machen.
Würde ich bei der 40k-Zeilen-Datei jedesmal nochmal extra eine Kopie speichern, brauche ich natürlich wesentlich mehr Platz, als wenn ich nur die handvoll Zeilen speichere, die geändert wurden.

Ausserdem ist es ja eigentlich auch nicht gedacht über 100 Versionen einer Datei in ein und dieselbe History zu speichern.
Irgendwann sollte ja mal etwas was man gebastelt hat released werden und die History dann eingefroren werden.
Von daher muss man normalerweise auch nicht ewig durch die Historys pflügen.

@HeX0R:

Vielleicht ne überflüssige Frage, aber: Du benutzt Transaktionen?

Grüße ... Kiffi

Kiffi hat geschrieben:Vielleicht ne überflüssige Frage, aber: Du benutzt Transaktionen?

Nein benutze ich nicht.
Es ist aber tatsächlich so, dass der Zeitaufwand des Datenbanktransfers wirklich nur ein Furz ist im Gegensatz zum Entzippen und Zusammenbauen der Historys.
Selbst mit meiner postgres-Datenbank, die auf einem Internet Server werkelt, merke ich keinen großen Unterschied in der Geschwindigkeit zu einer lokalen sqlite Datenbank.
Ich glaube nicht, dass das durch Transaktionen wirklich schneller würde.

Aber ich weiß es auch nicht, ich habe bisher noch nicht damit experimentiert.

HeX0R hat geschrieben:

NicTheQuick hat geschrieben:Wie wäre es denn, wenn du die letzte Version immer noch mal extra speicherst? Dann muss man nur nochmal alle vorherigen Versionen durchlaufen, wenn man einen oder mehrere Schritte zurück gehen möchte. So macht es doch z.B. auch SVN.

Naja, die Ursprungsidee war das ganze sehr platzsparend zu machen.
Würde ich bei der 40k-Zeilen-Datei jedesmal nochmal extra eine Kopie speichern, brauche ich natürlich wesentlich mehr Platz, als wenn ich nur die handvoll Zeilen speichere, die geändert wurden.

Ausserdem ist es ja eigentlich auch nicht gedacht über 100 Versionen einer Datei in ein und dieselbe History zu speichern.
Irgendwann sollte ja mal etwas was man gebastelt hat released werden und die History dann eingefroren werden.
Von daher muss man normalerweise auch nicht ewig durch die Historys pflügen.

Ok, wenn es nur für kleinere Sachen gedacht war, dann sehe ich das ein. Aber ich finde du solltest dir da trotzdem nochmal Gedanken über eine Option für den Nutzer machen. Also dass er eben selbst bestimmen kann, ob er lieber ein bisschen mehr Speicherplatz nutzen möchte und dafür schneller auf die letzte Version zugreifen kann. Das ist ja alles so eine Kompromisssache.

HeX0R hat geschrieben:

Kiffi hat geschrieben:Vielleicht ne überflüssige Frage, aber: Du benutzt Transaktionen?

Nein benutze ich nicht.

solltest Du aber bei SQLite machen. Da es sich hierbei um eine Datei-Datenbank handelt
(ohne dass ein Server dazwischenhängt), wird die DB bei jedem Insert / Update / Delete
direkt auf dem Datenträger geöffnet, bearbeitet und geschlossen.

Klammerst Du umfangreiche DB-Operationen mit 'Begin Trans' -- 'Commit', so werden diese
erst einmal im Speicher ausgeführt und dann (mit dem 'Commit') in einem Rutsch auf die
Platte geschrieben. Das erhöht die Geschwindigkeiten von SQLite-Operationen erheblich.

DB-Server (postgres & Co) sind IMO davon nicht betroffen. Da sollte man Transaktionen nur dann
verwenden, wenn man Sie auch gemäß ihres Zwecks wirklich benötigt (für die Durchführung eines
Rollbacks).

Da Thomas ja SQLite in Deinem Tool benutzt und er über nachlassende Performance klagt,
wäre es einen Blick wert.

Grüße ... Kiffi

Neue Version!

Der einfachheithalber das ganze aus dem englischen Übernommen:

Update V2.14

1. Improved History-Creation-Speed, so hv won't block your pc anymore at the end
2. Improved History Output:
   When selecting a history, the complete History will be loaded into memory.
   Then you can change between versions and/or templates nearly instantly
   (Well o.k., huge sources will still need some time to load into the WebGadget)
3. Put History Output in an extra threat
4. Fixed Copy/Move into released projects (No one realized this??)
5. Added possibility to copy historys (for starting new branches)
6. Added quickjump Window for Procedures and Structures (CTRL + I[nfo])
7. Some more things i forgot...

Windows-Version
Linux-Version

Gruß
Thomas

// edit
erledigt, jetzt geht es

Du hättest auch über hv direkt updaten können.