Parlons de la stratégie de stockage historique dans VSCode

VSCode a ajouté la fonction de conservation de l'historique local des fichiers. Cet article vous parlera de la stratégie de stockage de l'historique dans VSCode. J'espère que cela sera utile à tout le monde !

J'ai mis à jour VSCode hier et j'ai découvert que VSCode avait également ajouté la fonction de conservation de l'historique local des fichiers. Je me souviens qu'il n'y a pas si longtemps, afin d'ajouter une fonction d'enregistrement d'historique à Yank Note, je me suis gratté la tête et j'ai conçu une stratégie de stockage d'historique depuis longtemps. Je déplore que si VSCode avait été publié quelques mois plus tôt, j'aurais eu une référence. [Étude recommandée : "Tutoriel d'introduction à vscode"]

Mais quand j'ai regardé la stratégie de stockage historique de VSCode : si grossière ?

La stratégie de VSCode

L'historique local des fichiers peut être affiché dans la timeline de la version 1.66 de VSCode L'effet est comme ceci

Pour cette fonction, VSCode a également ajouté quelques configurations :

Là. Il y a également de nouveaux paramètres pour travailler avec l'historique local :

• workbench.localHistory.enabled - Activer ou désactiver l'historique local (par défaut : true).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.maxFileSize - Limite de taille de fichier lors de la création d'une entrée d'historique local (par défaut : 256 Ko).

workbench.localHistory.maxFileEntries - Entrées d'historique local limite par fichier (par défaut : 50).

workbench.localHistory.exclude - Modèles Glob pour exclure certains fichiers de l'historique local.

workbench.localHistory. mergeWindow - Intervalle en secondes pendant lequel d'autres modifications sont ajoutées à la dernière entrée de l'historique du fichier local (par défaut 10s).

Cliquez avec le bouton droit sur l'entrée de l'historique, il y a un menu accessible directement dans le gestionnaire du système. Une copie de l'historique d'un fichier.

On peut donc en déduire que VSCode enregistre un fichier dans le dossier dans une certaine fenêtre de temps (10 s par défaut) pour chaque opération de sauvegarde/annulation. Les enregistrements historiques sont localisés grâce à une dénomination de fichier spéciale (conservation des informations temporelles).

C'est trop grossier, un fichier n'est qu'une version.

La stratégie de Typora

Parlons ensuite de la stratégie de Typora qui a fait l'objet d'une enquête à cette époque. Typora a une très belle interface de retour en arrière de l'historique des fichiers sur macOS

Il semble qu'il devrait utiliser la "machine à voyager dans le temps" du système pour implémenter le retour en arrière des versions. Cette fonctionnalité n'est donc plus disponible sous Windows.

• La stratégie de Yank Note

• La version historique que j'envisage a plusieurs objectifs :

• L'objectif le plus important est d'éviter autant que possible la perte de données.

• Les enregistrements historiques ne doivent pas prendre trop de place, il est préférable de les enregistrer progressivement.

Dans les cas extrêmes, il est nécessaire de faciliter la restauration des données par les utilisateurs.

L'historique doit pouvoir marquer et prendre des notes

Pour le premier objectif, j'espère conserver la version modifiée la plus récente de l'utilisateur et ne pas la supprimer. Et Yank Note a une fonction de sauvegarde automatique, il a donc un deuxième objectif, ne pas prendre trop de place, et ne pas générer trop de fichiers. Ainsi, la stratégie de fenêtre temporelle + sauvegarde de fichiers à laquelle j'ai pensé à l'origine, similaire à VSCode, ne fonctionnera pas.

Pour le troisième objectif, je ne souhaite pas introduire de formats personnalisés, tels que Git, ou de bases de données. Parce que si l'utilisateur perd des données et qu'il n'est pas pratique de retrouver l'historique dans le logiciel (le logiciel est endommagé, les fichiers sont accidentellement supprimés, etc.), l'utilisateur doit pouvoir accéder au répertoire historique et récupérer les fichiers.

Suivi : Un utilisateur a accidentellement supprimé un document et la corbeille n'a pas pu le trouver, il l'a donc restauré via cette méthode.

• Considérant le quatrième objectif, j'ai finalement choisi d'utiliser des fichiers zip pour enregistrer la version historique du fichier, même si cela consommera un peu de performances informatiques en écriture et en lecture de l'historique (l'historique d'un gros fichier de plus de 10 mégaoctets est). fondamentalement inutile). mais le résultat final est plutôt bon.
• Solution finale :

• Chaque document est composé du nom du fichier et du chemin Hash pour épeler le nom du fichier du package zip

• Chaque fois qu'un fichier est écrit, une nouvelle version du fichier est écrite dans ce zip fichier en même temps

• Lors du déplacement et du renommage de fichiers, le nom du fichier zip peut être modifié simultanément
  🎜🎜Le nombre maximum de versions historiques peut être limité. 🎜🎜🎜🎜Les notes de version et les informations sur les balises peuvent être stockées dans des champs de notes compressés. 🎜

Habituellement, lors de l'édition d'un fichier, en raison du mécanisme de sauvegarde automatique, la différence entre la version actuelle et la version précédente est très faible. Par conséquent, en ajoutant théoriquement une nouvelle version du fichier compressé, la taille globale du fichier compressé. devrait augmenter considérablement. Mais plus tard, j'ai découvert que ce n'était pas le cas. Ce n'est qu'à ce moment-là que j'ai réalisé les caractéristiques de la compression de fichiers Zip : chaque fichier est compressé séparément puis regroupé. C'est-à-dire que lors de l'ajout de fichiers au package compressé, ils ne seront pas compressés avec d'autres fichiers.

En réponse à cette situation, j'ai adopté une stratégie de double compression : la première fois, j'ai fixé le taux de compression à 0 et je l'ai uniquement empaqueté, afin que le package zip contienne les informations d'origine du fichier. L'intégralité du fichier emballé est compressée une fois pour la deuxième fois. Le programme de compression peut désormais prendre en compte les informations globales pour la compression, ce qui atteint l'objectif de « mise à jour incrémentielle ».

En écrivant un script plus tard pour tester, un fichier de longueur ordinaire, enregistrant 1000 versions, ne prend que 50 Ko.

Après l'avoir utilisé pendant plusieurs mois, mon répertoire de fichiers d'historique n'occupe que plus de 700 Ko d'espace, et la plupart des fichiers d'historique qu'il contient ne font que quelques Ko. En regardant VSCode, le répertoire historique occupait 2 M au cours des deux derniers jours.

Plus loin

Pour le stockage historique, j'ai en outre réfléchi à certaines stratégies de préservation

Par rapport à la dernière heure de sauvegarde, conservez :

• Chaque version des 10 dernières minutes
• La dernière heure Une version toutes les minutes au cours des dernières 24 heures
• Une version toutes les heures au cours des dernières 24 heures
• Conservez une version chaque jour
• Sauvegarde étiquetée

Mais il semble que ce ne soit pas nécessaire maintenant. La stratégie actuelle est simple. et répond à mes exigences dans tous les aspects attendus.

Pour plus de connaissances sur VSCode, veuillez visiter : Tutoriel vscode ! !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!