Which version control system to choose for regular files and documents?

Question

Database

Win7/8/10 platform.
You need a system, program or addition to the standard Windows Explorer, which would archive and record changes to certain files / s or ordinary documents.
Ideally, the system itself sees that such and such a file has changed, while it sends the previous copy of the file to the archive and asks the user for the reason for the current file changes for logging and history.
Those. you need something like standard shadow copies, but at the same time, changes (entered by the user) are indicated opposite each copy with information about what exactly was changed and why.
And the best thing is if such a software also works with files by analogy with virtual machine snapshots (with a tree of different file versions and with the ability to merge).
Advise something, plz, otherwise the search engines offer me "control of the program code" for my requests, etc. similar, which is not what I need.
UPD. Details and Description
Globally, the problem is as follows.
There is some purchased software that stores its data in SQLite or in Excel files (xlsx) (you can export).
The arrays are very huge, + are constantly updated with new data, while in most cases work is carried out only with a very small part of the database.
There was an idea to divide such a database into "hot" and "cold", periodically dumping unnecessary data into the "cold" part.
It is enough to do it manually, there is no need to talk about any automation.
In other words, it is enough just to make a copy of the current database with handles once a week, deleting "cold" data in the fresh copy.
In total, in the last copy that is being worked on - "hot" data, in archived copies - "cold" data. This is how the problem of both backup and "facilitation" of the current database is solved.
But at the same time, a system for accounting for versions of "cold" copies of the database is very necessary. periodically they are also needed in the work.
-------------------------------------------------- -------------------------------------------------- -------------------------------
The software is proprietary, of course, there is no access to the software stuffing. The fact that it is on SQLite is just a confident assumption, because. in the subfolder with the program there is a file "\RestoreBD\sqlite3.exe"
Further, when you try to open a database file through SQLiteStudio, the database file opens normally, despite the proprietary extension in the file name.
The entire structure in SQLiteStudio is visible, nothing is obfuscated, even the columns are named as understandable variables, and all data is read in the same way as in proprietary software. Those. the file with the base is by no means tightly closed and not encrypted (only the file extension is changed).
This proprietary software works with one database per unit of time, i.e. physically - with one database file. Therefore, I need to physically divide the database into several files in order to work with a database weighing several megabytes rather than several gigabytes. It is important not to forget where, what and in what form is stored. For this, some kind of versioning system for regular files is needed.
-------------------------------------------------- -------------------------------------------------- -------------------------------
Now there are about 140 tables in the database, each of which has 126 columns, and 100 to 300,000 records.
From each table, I need 0.01% -10% of the data that I get by sampling.
I want to save the selection separately, and work only with it ("hot base"), leaving the rest in the "cold" base.
Periodically, I make a new sample, and work with it.
If I manually save my selection, then the files “2017-03-10, such-and-such a project, such-and-such a selection” or “2017-03-17, such-and-such a project, such-and-such data have been deleted” begin to multiply, which, upon reaching there are more than 3-5 such files already leads to confusion and an attempt to figure out where exactly the specific data that is needed at a given time is contained.
As a result, I abandoned this option of manually copying and naming files, and I work with a 1.5 Giga file, which greatly affects performance.

Answer 1

zamboga : binary or text copies of the database? If binary - you will not see the delta of changes there. If text - that is a chance. But you need to understand that a database dump, even in text form, is not configs or source codes, and not even a text document, so under certain conditions any version control system can go crazy (for example, the sort order of tables will change for some reason when uploading to a dump), and then there will be no delta either. More precisely, technically it will, of course, but it will be absolutely useless.
And comments to the version, of course, will work in this case.

Answer 2

Which version control system to choose for regular files and documents?

Horses and people mixed up in a bunch ... You can use the built-in capabilities of the systems used. In addition to the change tracking system included in Windows, you can enable change tracking in MS Office files with the addition of additional information (who, when, why). In the DBMS, you can make full or differential backups, both in a separate file, and in the same one - it will be possible to track if you specify who, when, why.

There was an idea to divide such a database into "hot" and "cold",

That 's what segmentation is for .
google