Ben Collins-Sussman wrote:
> Andy Whitcroft wrote:
>
>> It appears that the client file modification detection is incorrectly
>> checking modification time and assuming that if that is unchanged the
>> file is unchanged even in the face of the size/inode number changing.
>
>
> That is exactly what's happening. SVN uses the same algorithm as CVS
> to detect if a file has changed:
>
> if (file's timestamp == one recorded in .svn/entries)
> return NOT_CHANGED
> else if (size of file != size of .svn/text-base/file)
> return CHANGED
> else
> compare file and .svn/text-base/file byte-by-byte.
>
> So what you're doing is 'mv'ing a different file with identical
> timestamp on top of the file, and the algorithm is falling down.
>
> Developers: is this a legitimate hole in our algorithm? Should we
> change it to cover this edge-case?
As a datapoint, StarTeam, *spit*, uses timestamps as the default
mechanism for detecting modifications, but has the option of using
md5sums instead. With md5 turned on it runs a lot slower, but sometimes
you do need it (mainly to work around other brokenness in StarTeam).
If Subversion is storing MD5s for the text bases anyhow, shouldn't the
comparison use the MD5 instead of being byte-for-byte?
Cheers,
Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 22 21:29:19 2004