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

Re: Bug with revisions?

From: Bryan Donlan <bdonlan_at_gmail.com>
Date: 2004-07-15 20:41:01 CEST

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

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

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.