Modified checkout undetected by Fossil
(1.1) By Dan Shearer (danshearer) on 2020-10-01 14:48:34 edited from 1.0 [source]
I had an unexpected incident with Fossil compiled from trunk today. Then I found a credible description of the same thing online:
In certain circumstances, in a check-out that already contains the trunk's code, running "fossil diff" and "fossil status" will reveal no changes, even though the trunk has been changed.
What are these "certain circumstances" ?
I started again from scratch and was unable to reproduce it, but it definitely happened.
Dan Shearer
(2) By aitap on 2020-10-01 15:02:54 in reply to 1.1 [link] [source]
I stumbled upon this when modified file didn't have its mtime
changed. I used a script to reproduce a problem when merging files containing
UTF-8 BOM and it worked too fast, making Fossil ignore the edits.
The logic to catch this (and re-check files, even if their mtime suggests them
being unedited) on commit does exist, though.
(3) By Dan Shearer (danshearer) on 2020-10-01 15:57:15 in reply to 2 [link] [source]
aitap on 2020-10-01 15:02:54:
The logic to catch this (and re-check files, even if their mtime suggests them being unedited) on commit does exist, though.
Are you referring to the --hash parameter on 'changes' and 'commit'?
And the --mtime parameter on 'checkout'?
If so, that makes sense to me.
Here's a very thorough mtime discussion of why neither mtimes nor hashes on their own will solve this problem completely. I'm partially satisfied that I may have triggered one of the many, many conditions listed here and that if so, there is nothing Fossil can do to completely avoid this. Unless it is by using both hashes and mtime, and maybe the more-sensitive ctime.
That feels like a reasonably satisfactory explanation to me.
Dan Shearer