Strange race-condition/possible bug in Subversion 1.7.0

[Harald Wilhelmi <ha...@tngtech.com>]

Hi,

in the last weeks I developed a little Subversion tool. When I
heard about Subversion 1.7.0 I downloaded the source at the next
opportunity to run the functional tests against the new version.
With the new version two of the tests fail *sometimes*. The
tests use the command line and do about this:
                                             
    echo -n xxx >a                           
    svn add a     
    svn commit -m 'c1' .

    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?
Is it already a known issue?

So far I have not subscribed to the list, so please answer also to
my personal address.

Regards                                      
Harald Wilhelmi

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

[Daniel Shahaf <d....@daniel.shahaf.name>]

Les Mikesell wrote on Wed, Oct 19, 2011 at 18:06:37 -0500:
> On Wed, Oct 19, 2011 at 3:58 PM, Harald Wilhelmi
> <ha...@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.

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

[Les Mikesell <le...@gmail.com>]

On Wed, Oct 19, 2011 at 3:58 PM, Harald Wilhelmi
<ha...@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.

-- 
  Les Mikesell
    lesmikesell@gmail.com