I am using a repository on an encrypted volume (V:) which is sitting on an external USB SSD (W:).
Whenever something goes wrong with the mounted partition (e.g. the cable was disconnected for a millisecond, or the I/O driver had a hiccup), 99% of the Applications accessing the volume are able to continue working properly, worst case they crash, but no data is lost.
However, usually when this happens, my repository gets slightly corrupted. I am not sure whether tortoiseHg Workbench has to be openend at the time it occurs, or whether it is enough that the TortoiseHG Overlay Icon Service is running in the background.
The symptom for this corruption is the "Not a head revision" message in the TortoiseHg Workbench, looking like this (not my own screenshot):
A 100% working fix for this situation is running
hg debugrebuildstate -r tip
if I am currently working on the tip revision or
hg debugrebuildstate -r 20939
if 20939 was my active revision before the corruption occurred.
I am happy that I am always able to resume working quickly after a repository corruption like this happened, but I am curious whether it is possible to reduce the chances of it happening in the future.
I appears to me that the file /.hg/dirstate is the source of the situation. In certain intervals, I am observing a second file, e.g. dirstate-c353d00c, appearing and quickly disappearing. I assume that this means that the dirstate gets updated at that time, and if something goes wrong during that operation, my repository gets corrupted, but only the flag for the revision that's active is affected, nothing else gets lost.
Could the process of updating the dirstate be modified to prevent the kind of corruption I am experiencing from occuring?