On Mar 15, 2005, at 3:23 PM, Travis P wrote:
>
> On Mar 15, 2005, at 8:31 AM, Ben Collins-Sussman wrote:
>
>> Yes, there is a common function used throughout the svn codebase --
>> its only purpose is to return a "yes" or "no" answer to the question,
>> "has this file been changed by the user?" I think it's called
>> svn_wc_text_modified_p().
>>
>> The algorithm is extremely similar to what CVS does:
>>
>> stat working and textbase files.
>> if (mtimes of working and textbase are equal):
>> return NOT_CHANGED;
>> else if (filesizes of working and textbase are unequal):
>> return CHANGED;
>> else
>> compare the files byte-by-byte. /* very slow */
>>
>> This function is used by 'svn status', 'svn commit', 'svn update',
>> and many other commands. Without the mtime check, these command
>> commands would be EXTREMELY slow.
>
> Ben,
>
> I'm curious why you don't use this alternative heuristic as less
> likely to return a false answer and no slower (I'm making the common
> assumption that getting mtime and size are both stat operations that
> are fetched in one operation):
>
> if (filesizes of working and textbase are unequal):
> return CHANGED;
> else if (mtimes of working and textbase are equal):
> return NOT_CHANGED;
> else
> compare the files byte-by-byte. /* very slow */
>
Why is this less likely to return a false answer?
And also, I'd argue this is slower. 99% of the time, almost every file
in the tree will be unchanged, and will have identical working/textbase
timestamps. Using the current algorithm, it means that 99% of the time
we get a definitive "answer" to the question on the first comparison.
In your algorithm, we'd end up doing two comparsions nearly all the
time, instead of one.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 16 04:49:13 2005