> -----Original Message-----
> From: Daniel Widenfalk [mailto:Daniel.Widenfalk_at_iar.se]
> Sent: dinsdag 18 mei 2010 10:00
> To: Dan Stromberg
> Cc: users_at_subversion.apache.org
> Subject: Re: race condition on checkin immediately followed by a merge?
>
> Hi Dan,
>
> Dan Stromberg wrote:
> > <snip>
> > The code I'm aiming to replace has had a longstanding problem with SVN
> > reliability. ISTR that one of the issues was that a change would be
> > checked in, and then checked back out (or merged), and the change just
> > made would seem to not be there - for a while, just long enough to
> > cause a merge issue in an automatic merge program. Then the next time
> > you check, the change is there, as though nothing had ever been wrong.
> >
> > And I'm now seeing precisely the issue described above not in the new
> > program (not yet at least), but in a unit test for the new program.
> > The unit test is checking out a file with an integer in it, adding one
> > to the integer, checking it back in, checking out the prior rev to a
> > different WC, then merging to the latest rev. It's usually fine doing
> > this, but once in a while the integer seems to have not been
> > incremented.
>
> Subversion uses a simple heuristic to determine if a file has
> changed. It is well documented in the source code but perhaps
> not so well known:
>
> If the size and time stamp of a file is the same as when checking
> out the file it is immediately considered as unchanged. We had a
> similar issue where an automatic script failed to commit an updated
> file.
>
> This is most easily resolved by adding a small delay between checking
> out and performing the modification. We used 2 seconds. You need to
> wait long enough for your operating system file time stamp to tick
> one step and on Windows this means about 2 seconds to be sure.
On Windows and most operating systems this depends on the filesystem being
used.
On NTFS you should never see issues like these as the timestamps have 100
nanosecond precision. On FAT (including FAT32, but not including the newer
VFAT) however you *do* see this issue.
(On linux: Ext3 has 1 second precision and Ext4 has nanosecond precision.
HFS+ on the mac has 1 second precision)
Subversion tries to compensate for 1 second precision filesystems, but this
is not guaranteed accurate for network filesystems and systems that use 2
second precision. (It waits until the time changed to the next second before
returning from for these commands)
> There may be some option that can be specified when committing that
> forces a deeper check?
No, there is no standard deeper check option.
Bert
Received on 2010-05-18 10:20:51 CEST