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

Re: race condition on checkin immediately followed by a merge?

From: Daniel Widenfalk <Daniel.Widenfalk_at_iar.se>
Date: Thu, 20 May 2010 08:28:45 +0200

Hi Dan,

Dan Stromberg wrote:
> On Tue, May 18, 2010 at 1:20 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>>> 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)

Yes, IIRC we saw this problem on a network mounted directory
which explains the 2 second jitter.

> Folks seem to be saying that this is an issue in the SVN client's
> working copy filesystem, not the SVN server's repository filesystem.
> Is that correct?

I may have misinterpreted your original problem.

What I explained results in files not being committed at all!
Your problem seems that a successful commit is not immediately
available. Correct?

> What part of this process would be dependent on the filesystem's
> timestamp resolution:
>
> 1) Check out file n from srcurl rev 1000 to working copy 1, wc1
> 2) Pull the sole value out of n - an integer
> 3) Increment the integer

Here is where you'd need to wait a small amount of time before
updating the file.

> 4) Check n back in to srcurl with the increased value to srcurl rev 1001
> 5) Check out file n from dsturl rev 1000 to a new working directory,
> wc2 (dsturl is a mirror of srcurl, but a little older)
> 6) svn merge from srcurl at rev 1000 into wc2
> 7) checkin modified wc2 to dsturl
>
> ?
>
> I'm guessing it's a matter of step 7 (near the beginning, when a
> freshness check is applied to n) seeing the same mtime and file size
> on file n as it had in step 5 (near the end, when n is written). Is
> that correct?

I think that it is only in step 3, e.g. when doing the original
update on the file, that you can stumble onto the file-not-changed
heuristics. The svn merge will most probably work as expected.

What server setup are you using? svnserve or Apache? Are you using
write-through proxy with replication to read-only mirrors? Re-reading
your description it seems that it is step 6 that fails (no new
revision to merge).

Since both server solutions are multi-threaded it might be that the
processing of the commit in step (4) above has not been fully
completed (and mirrored?) in time for when you initiate step (6).
What kind of timing do you have between the steps? I would guess
that 1-2-3-4 and 5-6-7 are fairly fast and that there may be some
time N between steps 4 and 5?

Regards
/Daniel Widenfalk
Received on 2010-05-20 08:29: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.