Lassen Sie uns über die historische Speicherstrategie in VSCode sprechen

VSCode hat die Funktion zum Speichern des lokalen Verlaufs von Dateien hinzugefügt. Ich hoffe, dass er für alle hilfreich ist.

Ich habe gestern VSCode aktualisiert und festgestellt, dass VSCode auch die Funktion zum Beibehalten des lokalen Dateiverlaufs hinzugefügt hat. Ich erinnere mich, dass ich mir vor nicht allzu langer Zeit den Kopf zerbrochen habe, um Yank Note eine Funktion zur Verlaufsaufzeichnung hinzuzufügen, und mir lange Zeit eine Strategie zur Speicherung des Verlaufs ausgedacht habe. Ich bedauere, dass ich eine Referenz gehabt hätte, wenn VSCode ein paar Monate früher veröffentlicht worden wäre. [Empfohlene Studie: „

Vscode-Einführungs-Tutorial

“]Aber als ich mir die historische Speicherstrategie von VSCode ansah: So grob?

VSCodes Strategie

Der lokale Verlauf von Dateien kann in der Zeitleiste von Version 1.66 von VSCode angezeigt werden. Der Effekt ist wie folgt:

Für diese Funktion hat VSCode auch einige Konfigurationen hinzugefügt:

Dort Es gibt auch neue Einstellungen für die Arbeit mit dem lokalen Verlauf:

workbench.localHistory.enabled – Aktiviert oder deaktiviert den lokalen Verlauf (Standard: true).

• workbench .localHistory.maxFileSize – Dateigrößenbeschränkung beim Erstellen eines lokalen Verlaufseintrags (Standard: 256 KB).workbench.localHistory.enabled - Enable or disable local history (default: true).
• workbench.localHistory.maxFileSize - File size limit when creating a local history entry (default: 256 KB).
• workbench.localHistory.maxFileEntries - Local history entries limit per file (default: 50).
• workbench.localHistory.exclude - Glob patterns for excluding certain files from local history.
• workbench.localHistory.mergeWindow - Interval in seconds during which further changes are added to the last entry in local file history (default 10s
workbench.localHistory.maxFileEntries – Lokale Verlaufseinträge Limit pro Datei (Standard: 50).

workbench.localHistory.exclude – Glob-Muster zum Ausschließen bestimmter Dateien aus dem lokalen Verlauf.

workbench.localHistory. mergeWindow – Intervall in Sekunden, in dem weitere Änderungen zum letzten Eintrag im lokalen Dateiverlauf hinzugefügt werden (Standard 10s).

Rechtsklick auf den Verlaufseintrag, es gibt einen Menü, das direkt im Systemmanager zu finden ist. Eine Kopie des Dateiverlaufs.

Daraus kann geschlossen werden, dass VSCode bei jedem Speicher-/Rückgängig-Vorgang innerhalb eines bestimmten Zeitfensters (Standard 10 Sekunden) eine Datei im Ordner speichert. Historische Aufzeichnungen werden durch eine spezielle Dateibenennung (unter Beibehaltung von Zeitinformationen) lokalisiert.

Das ist zu unhöflich, eine Datei ist nur eine Version.

Typoras Strategie

Dann lassen Sie uns über die damals untersuchte Strategie von Typora sprechen. Typora verfügt unter macOS über eine sehr schöne Schnittstelle zum Zurückverfolgen des Dateiverlaufs

Es scheint, dass es die „Zeitmaschine“ des Systems verwenden sollte, um das Zurückverfolgen von Versionen zu implementieren. Daher ist diese Funktion unter Windows nicht mehr verfügbar.

Die Strategie von Yank Note

• Die historische Version, die ich mir vorstelle, hat mehrere Ziele:

• Das wichtigste Ziel besteht darin, Datenverluste so weit wie möglich zu vermeiden.

• Historische Aufzeichnungen sollten nicht zu viel Platz beanspruchen, es ist am besten, sie inkrementell aufzuzeichnen.

• In extremen Fällen ist es notwendig, Benutzern die Wiederherstellung von Daten zu erleichtern.

Historische Aufzeichnungen sollten markiert und notiert werden können

Für das erste Ziel hoffe ich, die zuletzt bearbeitete Version des Benutzers zu behalten und sie nicht zu verwerfen. Und Yank Note verfügt über eine automatische Speicherfunktion, sodass es ein zweites Ziel hat: nicht zu viel Platz zu beanspruchen und nicht zu viele Dateien zu generieren. Daher wird die von mir ursprünglich in Betracht gezogene Strategie zum Speichern von Zeitfenstern und Dateien, ähnlich wie bei VSCode, nicht funktionieren.

Was das dritte Ziel betrifft, möchte ich keine benutzerdefinierten Formate wie Git oder Datenbanken einführen. Denn wenn der Benutzer Daten verliert und es unpraktisch ist, den Verlaufseintrag in der Software zu finden (die Software ist beschädigt, die Datei wurde versehentlich gelöscht usw.), muss der Benutzer in der Lage sein, das Verlaufsverzeichnis aufzurufen und die Datei abzurufen.

Follow-up: Ein Benutzer hat versehentlich ein Dokument gelöscht und der Papierkorb konnte es nicht finden, also hat er es mit dieser Methode wiederhergestellt.

• In Anbetracht des vierten Ziels habe ich mich schließlich für die Verwendung von Zip-Dateien zum Speichern der historischen Version der Datei entschieden, obwohl dies beim Schreiben und Lesen des Verlaufs ein wenig Rechenleistung verbraucht (der Verlauf einer großen Datei mit mehr als 10 Megabyte ist). grundsätzlich nutzlose Wahrnehmung), aber das Endergebnis ist ziemlich gut.
  Die endgültige Lösung:

• Jedes Dokument besteht aus dem Dateinamen und dem Pfad-Hash, um den Dateinamen eines Zip-Pakets zu buchstabieren.

• Jedes Mal, wenn eine Datei geschrieben wird, wird eine neue Versionsdatei in diese Zip-Datei geschrieben gleichzeitig

• Beim Verschieben und Umbenennen von Dateien kann gleichzeitig der Name der Zip-Datei geändert werden

• Die maximale Anzahl historischer Versionen kann begrenzt werden. 🎜🎜🎜🎜Versionsnotizen und Tag-Informationen können in komprimierten Notizfeldern gespeichert werden. 🎜

Normalerweise ist beim Bearbeiten einer Datei aufgrund des automatischen Speichermechanismus der Unterschied zwischen der aktuellen Version und der vorherigen Version sehr gering. Daher verringert sich theoretisch die Gesamtgröße der komprimierten Datei, wenn man der komprimierten Datei eine neue Versionsdatei hinzufügt sollte deutlich zunehmen. Aber später stellte ich fest, dass dies nicht der Fall war. Erst dann erkannte ich die Eigenschaften der Zip-Dateikomprimierung: Jede Datei wird einzeln komprimiert und dann zusammen gepackt. Das heißt, wenn Dateien zum komprimierten Paket hinzugefügt werden, werden diese nicht zusammen mit anderen Dateien komprimiert.

Als Reaktion auf diese Situation habe ich eine Zwei-Komprimierungsstrategie übernommen: Beim ersten Mal habe ich die Komprimierungsrate auf 0 gesetzt und sie nur gepackt, sodass das ZIP-Paket die Originalinformationen der Datei enthielt. Die gesamte gepackte Datei wird ein zweites Mal komprimiert. Jetzt kann das Komprimierungsprogramm die Gesamtinformationen für die Komprimierung berücksichtigen, wodurch der Zweck der „inkrementellen Aktualisierung“ erreicht wird.

Wenn Sie später ein Skript zum Testen schreiben, benötigt eine Datei normaler Länge, die 1000 Versionen speichert, nur 50 KB.

Nachdem ich es mehrere Monate lang verwendet habe, nimmt mein Verlaufsdateiverzeichnis nur mehr als 700 KB Speicherplatz ein, und die meisten darin enthaltenen Verlaufsdateien sind nur wenige KB groß. Rückblickend auf VSCode belegte das Verlaufsverzeichnis in den letzten zwei Tagen 2 Millionen.

Weitere

Für die historische Speicherung habe ich weiter über einige Aufbewahrungsstrategien nachgedacht Eine Version pro Minute für die letzten 24 Stunden Die Strategie ist einfach und erfüllt meine Anforderungen in allen erwarteten Aspekten.

Weitere Informationen zu VSCode finden Sie unter:

vscode-Tutorial

! !

Das obige ist der detaillierte Inhalt vonLassen Sie uns über die historische Speicherstrategie in VSCode sprechen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!