On Thu, 15 Jul 2004 13:34:31 -0500, Ben Collins-Sussman
<sussman@collab.net> wrote:
> On Thu, 2004-07-15 at 13:16, Kasia Trapszo wrote:
> > I ran into this problem today and it looks to be a nasty bug..
> >
> > File was changed, but the timestamp on the file is the same as the
> > previous revision. Running svn diff shows no difference and cannot
> > commit the file to the repository (as subversion thinks it hasn't been
> > edited). Do a normal diff on the file (not svn) and there's a
> > difference.. Do a 'touch' to change the date and now svn sees the
> > difference.
> >
> > This should be easy to reproduce.
>
> This isn't a bug, it's a deliberate SVN design. SVN algorithm uses the
> same algorithm as CVS to decide if a file has changed:
>
> if (timestamp unchanged)
> return FILE_UNCHANGED;
> else if (filesize changed)
> return FILE_CHANGED;
> else
> return do_brute_force_byte_for_byte_comparison();
>
> If the timetstamp-trick weren't the first line of defense, then it would
> take *hours* to run 'svn status', or run 'svn commit'.
Wouldn't it be better to check the filesize first? On *nix at least
both size and time could be checked with one function call, and if
timestamp resolution (like in FAT) stops the timestamp from changing
there's at least a chance it'd be detected.
--
bd
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 15 20:41:24 2004