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

Re: SVN status and diff showing no modifications (svn 1.4.4 (r25188))

From: Archie Cobbs <archie_at_dellroad.org>
Date: Wed, 7 May 2008 20:52:48 -0500

On Wed, May 7, 2008 at 5:55 PM, eg <egoots_at_gmail.com> wrote:

> eg wrote:
>
> > Archie Cobbs wrote:
> >
> > > Apparently this is a timestamp issue. The
> > > checkout/trunk/dir1/.svn/entries file contains this:
> > >
> >
> <snip>
>
> > My understanding is that Subversion has an internal function
> > svn_sleep_for_timestamps() which is supposed to prevent this case from
> > happening.
> >
> > I am not one of the developers, but this does sound like a bug to me.
> >
>
> Snooping into this a bit further.
>
> See issue 2746 it sounds similar (if not identical):
> http://subversion.tigris.org/issues/show_bug.cgi?id=2746
>

There is an important difference... namely, that bug requires manually
fiddling with the timestamp to artificially back-date the modified file.

My bug occurs without doing that... though I'm pretty sure the checkout and
modification steps have to occur within the same second of time. This would
not happen in normal usage, but there are plenty of automated scripts (e.g.,
wiki and webdav stuff) that might trigger it.

> It looks like Erik Huelsmann did a fix for this and it appears that it is
> in 1.5.
>

Only if the filesize changes. IMHO that's not a complete fix. E.g., imagine
an automated script that just changes some number in a file (e.g., from
"version=1.2" -> "version=1.3").

Why don't they check the timestamp, then the filesize, and only then check
the contents? After finding differences, they could a flag or update the
timestamp to avoid duplicate checks.

Hmm.

-Archie

-- 
Archie L. Cobbs
Received on 2008-05-08 03:53:31 CEST

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.