On Friday 19 January 2007 22:16 Gunter Ohrner wrote:
> testcase2.sh:
>
> I found a case where fsvs 1.0.15 misses a change which was correctly
> recognized by fsvs 1.0.14.
>
> A test case script is attached. In this test case, the working copy moves
> and is resynchronized via sync-repos. A file in the moved working copy
> has been changed before.
>
> fsvs 1.0.15 misses the update of "Datei2" and the last line of the script
> returns "Datei2" instead of "Datei3" which would be correct.
>
> The "fsvs status" after the sync-repos shows that fsvs incorrectly thinks
> that the working copy is in sync.
I'll take a look.
> Additionally I have a further question:
>
> Without the "sleep", fsvs misses the update completely, as the file's
> mtime doesn't change. If you know it, it's obvious, and it's a case
> which should rarely happen in a production system, but I was still a
> bit surprised when it happened first.
It's not only about the file's mtime - it's the ctime (and the directories'
mtime, ctime too).
fsvs only stores the seconds, not micro- or nanoseconds, as most filesystems
don't have them anyway ... so it won't find changes that happen in the same
second as an update or commit happens.
> testcase6.sh:
>
> Here, the working copy is recreated at the same place, with the same
> content. fsvs works correctly, but shows all file's meta-data to be
> changed. Why does that happen, and is this correct?
That'll be because of the ctime. That's discusseable, but on commit fsvs will
see that no content has changed, and do an empty commit - and afterwards it
won't show them as changed.
> Both fsvs 1.0.14 and 1.0.15 commit the correct changes.
See?
Thank you!
Regards,
Phil
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
