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

Re: Strange race-condition/possible bug in Subversion 1.7.0

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 20 Oct 2011 09:25:43 +0200

Les Mikesell wrote on Wed, Oct 19, 2011 at 18:06:37 -0500:
> On Wed, Oct 19, 2011 at 3:58 PM, Harald Wilhelmi
> <harald.wilhelmi_at_tngtech.com> wrote:
> >
> >    svn copy a b
> >    echo -n yyy >b
> >    svn commit -m 'c2' .
> >
> > Of cause I expect 'b' to contain 'yyy'. However sometimes it
> > contains 'xxx'. After this the repository is all consistent and fine
> > in my opinion (expect that 'a' has the unexpected content). However
> > the working copy looks strange. It behaves like that:
> >
> > 1) 'svn status' and 'svn diff' agree that there is no local change
> >   in 'b'.
> >
> > 2) If I just do a 'touch' on on 'b' without changing it's content,
> >   the svn command changes it's opinion. Now 'svn diff' and
> >   'svn status' agree that there is a local modification (xxx->yyy).
> >
> > Since I added the equivalent of a 'sleep 1' just after the 'svn copy'
> > I have not seen the issue again.
> >
> > Do you consider that a bug?
>
> Svn is going to look at the timestamps (and maybe the length) on the
> pristine copy and your visible working copy file and if they match,
> assume there are no differences. So you need at least the timestamp
> resolution of your filesystem difference between the creation and
> change.

It's possible that we lack an svn_sleep_for_timestamps() call somewhere,
or that that call sleeps for less than the timestamp resolution of your
disk's fs.
Received on 2011-10-20 09:26:28 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.