Branko Čibej <[email protected]> writes: > Didn't we have file size and modification time as additional checks if > a full-text compare was needed? The size is recorded in the wc-db and > should be even if the pristine file is absent, but the mtime is not, IIRC. > In any case, the more checks we use, the harder it is to construct a > collision.
Yes, we begin by comparing file sizes and modification times against the values stored in wc.db. This logic is identical for both pristineful and pristineless working copies. It gets slightly trickier with eol/keyword translation, but if no translation is needed, I think it boils down to this: - If both the sizes and timestamps match, the file is considered unmodified. - If the sizes differ, the file is considered modified. However, there are still cases where these quick checks are inconclusive. For example, if a file is modified but retains the same size, or if the on-disk timestamps have somehow changed. In those cases, we fall back to a content comparison via questions.c:compare_and_verify(): - In trunk, compare_and_verify() does not distinguish between pristineful and pristineless working copies and always performs a checksum-based comparison (for instance, because the pristine content is unavailable in the pristineless case). - In 1.14, compare_and_verify() always performs a content comparison between the pristine and the working file. I'm currently thinking that we could make compare_and_verify() perform a content comparison for pristineful working copies, to avoid changing more characteristics than necessary. So my plan was to sketch a patch to see how this translates into code. Thanks, Evgeny Kotkov
