[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: bug in svn diff and related?

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-03-15 15:31:28 CET

On Mar 15, 2005, at 7:33 AM, David Ripton wrote:

> On 2005.03.15 02:10:39 +0000, mike south wrote:
>> It looks to my untrained (and uninformed!) eye as though svn diff may
>> be
>> checking the mtime of a file against the
>> .svn/text-base/[filename].svn-base version (the "pristine copy") of
>> the
>> file, and skipping the diff if the mtimes are the same.
> I haven't actually looked closely at the code, but I believe this is
> the
> case.

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

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;
         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.

The libsvn_client functions are also very careful to put a 'sleep 1' in
at the correct places (just like CVS does), to exactly avoid the
situation you've described in your email.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 15 15:34:00 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.