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
SVN_I_LOVE_CORRUPTED_WORKING_COPIES_SO_DISABLE_SLEEP_FOR_TIMESTAMPS
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,
Tobias
PS: Please put me on CC when replying, I'm not subscribed to the mailing
list.
