Can Visual Studio remember MD5 from my source files to avoid recovering them when the timestamp changes, but not in the content?

Question

In most cases, I do several separate events in one project and in order to have some logical separation between them, I use a personal project version control system (namely fossil , but this is too many details).

This allows me to do my work in different branches, so that I can combine them later. In the meantime, I am supporting a trunk branch in which I am doing work on the part of my colleagues.

But when I switch from branch to another (to perform some merge action for example) and return to where I came from, Visual studio will detect timestamp modifications and rebuild files that have not actually been changed.

Can I ask Visual Studio that the source file changed when only a hash of its contents changed?

As it seems, the answer “no” is another way to achieve what I would like, for which I begin generosity. Still read above.

Do you know a simple way to have a snapshot of the timestamps and MD5 hashes of my source files, and then, for each file from which the timestamp has been changed, compare the MD5 and rollback timestamp modifications if MD5 has not changed?

Thank you for your responses.

Answer 1

I am afraid that this is really impossible.

The problem here is that this is not just a thing for VS, but actually for the entire build system, which is completely separate from the real IDE.
To decide if .obj needs to be compiled, VS compares its timestamp with the source file. Doing what you offer will require the .obj file to include the MD5 file. This also applies to .exe and .dll files. Changing the binary format of these files is unlikely to happen for such a rarely required function.

---

Change - I will take it, maybe it is possible in theory. One way is to write the VS plugin. The plugin will save MD5 in a file in the output directory, and before starting the assembly, the modified dates of the corresponding files will be updated.

Thinking more, it might be possible using the pre-assembly step.?

Answer 2

A simple workaround would be to write a script that looks at a file that Visual Studio does not know and, if it has changed, copies it to overwrite the file that Visual Studio knows about. The Visual Studio file sees that it is then excluded from the original control, so the timestamps should not touch.

The copying decision may be based on a hash, but it can also easily compare the source and destination files directly.

Visual Studio definitely has the ability to include code generators in the assembly, which would be the script in the eyes of Visual Studios. I don't know the details though ... I get cmake to manage these things for me.