On 10. 7. 25 21:50, EML wrote:
Hi -
On 10/07/2025 19:36, Branko Čibej wrote:
On 10. 7. 25 17:37, Johan Corveleyn wrote:
In general, the file in your $broken_workingcopy might have been
changed out-of-band, by some other tool, a virus, a disk failure, ...
but the main question is: why doesn't your $broken_workingcopy detect
that it's modified?
Is that a correct rephrasing of your question?
Subversion uses a shortcut when detecting changed files in the
working copy: if the file's size is the same size as recorded in the
metadata, and its modification time is the same as that recorded in
the metadata, svn assumes the file did not change.
Interesting - so it's like the default rsync opts. I can (almost)
understand 'svn status' doing this, but surely 'svn diff' should
actually carry out a byte-by-byte comparison if the sizes are the same?
Nope. It's the same optimisation: if the file "hasn't changed", no diff
is performed.
Consider that to actually get this state -- change a file without
changing its mtime -- you have to do this on purpose; normal usage will
never get there. The most likely events for this to happen are either
memory or disk corruption, or an OS bug. In which case all (well,
"most") bets are off.
This is not perfectly ideal, but the alternative -- scanning the file
bytes -- would slow down the working copy by at least an order of
magnitude. We've been there and decided that the shortcut was the lesser
evil.
-- Brane
