Shulou(Shulou.com)05/31 Report--

This article mainly introduces the relevant knowledge of "what is the history storage strategy in VSCode". The editor shows you the operation process through an actual case. The operation method is simple, fast and practical. I hope this article "what is the history storage strategy in VSCode" can help you solve the problem.

Strategy of VSCode

The local history of the file can be displayed in the timeline of VSCode version 1.66, and the effect is as follows

For this feature, VSCode has also added some configurations:

There are also new settings to work with local history:

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).

Right-click the history entry and there is a menu to find a copy of a history of the file directly in the system manager.

So it can be inferred that VSCode saves a file to a folder within a certain time window (default 10s) for each save / undo operation. Locate the history through special file naming (retention time information).

This is too rough, a file is a version.

Strategy of Typora

Then talk about the strategy of Typora that was investigated at that time. Typora has a very beautiful file history backtracking interface on macOS.

It seems that it is supposed to use the system's "time machine" to implement version backtracking. So this feature is not available on Windows.

Strategy of Yank Note

The historical version I envisioned has several goals:

The most important goal is to avoid data loss as much as possible.

Historical records do not take up too much volume, it is best to record them incrementally.

In extreme cases, it is convenient for users to restore data.

History should be able to mark and comment

For the first goal, I want to keep the user's latest edited version and not give up. And Yank Note has auto-save function, so there is a second goal, do not take up too much space, and do not generate too many files. So at first, the strategy of time window + file saving, similar to that of VSCode, is not good.

For the third goal, I don't want to introduce custom formats, such as Git, or databases. Because if the user loses data, it is not convenient for the software to find the history record (software damage, file deletion, etc.), the user can enter the history directory and retrieve the file.

Follow-up: a user deleted a document by mistake, and the Recycle Bin could not be found, so it was restored by this method.

Considering the fourth goal, I finally chose to use zip files to save the file history version, although it consumes a little computing performance in the write and read history (the history of more than 10 megabytes of files is almost unaware), but the end result is still very good.

Final plan:

Each document spells out a zip package file name from the file name and path Hash

Each time a file is written, a new version of the file is written to the zip file

Synchronously change the name of the zip file when moving and renaming the file

The maximum number of historical versions can be limited.

Version remarks and tag information can be stored in a compressed memo field.

Usually when editing a file, due to the automatic save mechanism, the difference between the current version and the previous version is very small, so theoretically add a new version of the file to the compressed file, the increase in the overall size of the compressed file should be very small. However, when I found out later that this was not the case, I realized the nature of Zip file compression: each file was compressed separately and then packaged together. In other words, when you add files to the archive, they will not be compressed with other files.

In response to this situation, I adopted the strategy of compression twice: for the first time, I set the compression ratio to 0 and just packaged it, so that the zip package was filled with the original information of the file. The second time the entire package file will be compressed once, so the compression program can consider the overall information to do compression, which achieves the purpose of "incremental update".

Later, write a script to test, a normal-length file, save 1000 versions, but also take up 50KB.

After a few months of use, my history file directory only takes up more than 700 KB space, and most of the history files are only a few KB in size. In contrast to VSCode, using the historical directory for these two days takes up 2m.

This is the end of the introduction to "what is the History Storage Strategy in VSCode". Thank you for your reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.