Philipp Marek wrote, On 07/03/07 14:22:
I would expect test.txt to be reported as Changed... am I missing
something?
    
No. AFAIK (without looking) sync-repos has a small bug, in that files *with 
the same size* are not reported as changed, because their mtime is read after 
syncing. (See mtime, ctime stamps above).

Bug:
   $ fsvs st -C -C
should report it (doing a checksum), and
   $ fsvs commit -C -C
too.
  
yep... -C -C was my *workaround*...

but... on  *big* directory (5095 files/dirs) I get Bus error when using -C -C (without... it works as expected...):

fsvs ci -m "<snip>" -C -C -d

<snip>

23:10:50.733 hlp__lstat[helper.c:316] ./var/html/galleries/pages/144.php: uid=700 gid=700 mode=0100664 dev=0xfd07 ino=774597 rdev=0x0 size=23949
23:10:50.733 ops___stat_to_action[est_ops.c:274] change = 24
23:10:50.733 cs__compare_file[checksum.c:280] checking for modification on ./var/html/galleries/pages/144.php
23:10:50.733 cs__compare_file[checksum.c:282] hashing ./var/html/galleries/pages/144.php
23:10:50.733 cs___end_of_block[checksum.c:498] manber reinit
23:10:50.733 cs___end_of_block[checksum.c:595] on return at fpos=0: 00000000 (databits= 0)
23:10:50.733 cs__compare_file[checksum.c:322] mapping 24703 bytes from 0
23:10:50.734 cs___end_of_block[checksum.c:579] manber found a border: 19714 F2AED6B5 45D40000 f065e5c2f2568c70de54a8f9f806a199
23:10:50.734 cs___end_of_block[checksum.c:595] on return at fpos=19714: 45D40000 (databits=7f)

Program received signal SIGBUS, Bus error.
[Switching to Thread -1208153728 (LWP 10517)]
0x0804b040 in cs___end_of_block ()
(gdb) bt
#0  0x0804b040 in cs___end_of_block ()
#1  0x0804bed7 in cs__compare_file ()
#2  0x0804fec1 in ops__update_single_entry ()
#3  0x0805b30d in waa__update_tree ()
#4  0x0805bc67 in waa__partial_update ()
#5  0x0805bd21 in waa__read_or_build_tree ()
#6  0x0804d136 in ci__work ()
#7  0x08050c72 in main ()


So, BTW ... why does your fsvs give no MD5 of that file?
  $ fsvs info big_file
  ....    588888  ./big_file
        Type:           file
        URL:            file:///tmp/ram/fsvs-test-1000/repos/trunk/big_file
        Status:         0x0 (unmodified)
        Flags:          0x0 (none)
        Dev:            20
        Inode:          16306
        Mode:           0100644
        UID/GID:        1000 (flip)/1000 (flip)
        MTime:          Wed Mar  7 19:57:53 2007
        CTime:          Wed Mar  7 19:57:53 2007
        WAA-Path:       /tmp/ram/waa/be/9b/c359b8d47483ea64ef5faa12ac2d/
        Revision:       4
        Repos-MD5:      9f588ff5001de34673652c4a767575e4
        Size:           588888

  $ echo 'Hello world!' | md5sum
  59ca0efa9f5633cb0371bbc0355478d8  -
Could you please check whether fsvs really prints no MD5 for you?
Why not?
  
Hmmm... probably because info was applied on the directory "."  ("fsvs info" without any path)...  not on test.txt...

$ fsvs info
....      4096  .
        Type:           directory

<snip>


Here on text.txt

$ fsvs info test.txt 
....        15  ./test.txt
        Type:           file
        URL:            file:///tmp/fsvs-test-repos/test.txt
        Status:         0x0 (unmodified)
        Flags:          0x0 (none)
        Dev:            64772
        Inode:          16421
        Mode:           0100664
        UID/GID:        700 (webmaster)/700 (webmaster)
        MTime:          Wed Mar  7 09:40:42 2007
        CTime:          Wed Mar  7 09:40:42 2007
        WAA-Path:       /tmp/fsvs-test-waa/c8/7a/49247ae33399f07ced864e301e46/
        Revision:       3
        Repos-MD5:      fd26eea2963d107fc314d4b92cc14333
        Size:           15
And now to your point - should fsvs on a sync-repos *always* check the local 
files for identity? (Doing a MD5?) Would be slow.
I would expect any synchronization function (probably only used when things go wrong...) to set the wc ready to be use as *business as usual*... and not having to care about using additional arguments on subsequent commands to be sure it's the case. A quick fix (?) could be to have something like:

fsvs sync-repos [-r rev] [-C [-C]]

So the user can decide between speed and the checksum peace of mind...
 Should it do that always on  status? Probably not.
  
I agree. Status needs no change.
But you're right, in that it could see the differing mtime, and say "possibly 
changed" - as it does with other files.

How's r726 for you?
Better. But [-C [-C]] on sync-repos would be perfect! ;-)

Ben.