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

Re: subversion-1.8.0-rc2: diff_test 60 fails

From: Tobias Bading <tbading_at_web.de>
Date: Mon, 27 May 2013 15:40:41 +0200

On 27.05.2013 12:43, Branko Čibej wrote:
> On 27.05.2013 09:59, Tobias Bading wrote:
>> Quick update:
>> The problem is definitely timestamp related. "touch 3449_spurious"
>> fixes a "corrupt" working copy, i.e. "svn status" and "svn diff" work
>> properly afterwards. I'll try to figure out why my machine is living
>> in its own timeline. All I can say after reading just a few lines of
>> python code is that I don't have
>> hard-wired to 'yes' :-).
> Well, that's a relief, at least.
> Can you please get two pieces of information:
> 1) run the "mount" command and past the line representing the ext4
> filesystem where your working copy lives

/dev/sdb1 on / type ext4 (rw,relatime,errors=remount-ro)

> 2) Get the ext4 superblock info, using "sudo tune2fs -l /dev/something";
> the mount output will tell you which /dev/something

tune2fs 1.41.11 (14-Mar-2010)
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: dcabb217-5e67-45ee-bbd1-bc78b9755514
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index
filetype needs_recovery extent flex_bg sparse_super large_file huge_file
uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 15269888
Block count: 61049088
Reserved block count: 3052452
Free blocks: 26233604
Free inodes: 13780922
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1009
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
RAID stride: 32730
Flex block group size: 16
Filesystem created: Tue Jul 5 15:41:05 2011
Last mount time: Mon May 27 09:14:16 2013
Last write time: Mon Apr 29 09:44:35 2013
Mount count: 18
Maximum mount count: 27
Last checked: Mon Apr 29 09:44:35 2013
Check interval: 15552000 (6 months)
Next check after: Sat Oct 26 09:44:35 2013
Lifetime writes: 1283 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
First orphan inode: 4072404
Default directory hash: half_md4
Directory Hash Seed: 3cc06f24-54d0-4435-94d0-d8ce07f75445
Journal backup: inode blocks

Further tests:
After the failed test, 'ls -l --full-time 3449_spurious' prints the
timestamp '2013-05-27 14:27:35.069850993 +0200'.
At this point, 'svn status 3449_spurious' claims that 3449_spurious is
unmodified. (This is what caused the test failure).

After a 'touch -d "2013-05-27 14:27:35.069850" 3449_spurious', 'ls -l
--full-time 3449_spurious' prints the timestamp '2013-05-27
14:27:35.069850000 +0200' and 'svn status 3449_spurious' still claims
that the file is unmodified.

After a 'touch -d "2013-05-27 14:27:35.069851" 3449_spurious', 'svn
status 3449_spurious' admits that the file has been modified.

This makes sense I guess, because apr_finfo_t has microsecond
resolution, whereas stat(2) (and ext4 obviously) have nanosecond
resolution. What doesn't make sense to me is why I have to patch
svn_io_sleep_for_timestamps to sleep a whole second. Waiting e.g. 0.1
seconds is not sufficient.

I tested a 'touch t1 ; touch t2 ; ... ; touch t50' and then 'ls -l
--full-time', which shows identical timestamps for all 50 files. Isn't
that a bit... odd?

Kind regards,

PS: Please put me on CC when replying, I'm not subscribed to the mailing
Received on 2013-05-27 15:41:21 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.