Hi, On Tuesday 18 November 2008 21:28:58 Philipp Marek wrote: > > > How can I solve this? I'd say the best solution is to "fsvs ignore" the > > R/O subfolders on the servers, but is there another solution? > > Well, of course FSVS can't change files on an read-only mount. > To get it "know" the last (current) version, you can use "sync-repos" - > which just fetches a new entry list from the repository, as reference point > to compare the WC against.
I used this solution once, manually, to solve the problem, but I wouldn't do it in a production environment, especially in an auto-commit script. > > Unfortunately, for the shared folders, FSVS finds that on backend2 some > > files have had their modification time modified, which is of course not > > the case. Even if I try to "fsvs revert" the guilty files, they always > > appear as being locally modified and "fsvs update" refuses to run. > > > > Again, is there a solution other than ignoring the shared folders on one > > of the backends, and thus versionning them on "backend1" only? > > That I can't explain ... > FSVS keeps timestamps in 1 second steps; so if the filesystem has a 2 > second granularity (like FAT), it might have this problem. But I don't > think that you're using FAT ;-) > [...] > > Or, wait a second ... if the directories you call "shared" are mounted on > both servers, is the problem (maybe) that backend1 commits changes, but > backend2 sees only the modified files but doesn't know about the commit, so > refuses to update? Yes maybe. So, finally, I decided to "unversion" the shared directories on the second server and to keep them on the first server only. That's the cleanest solution I think :) Thanks for your help. Regards, -- Farzad FARID / Architecte Open Source - Associé Pragmatic Source / http://www.pragmatic-source.com Tel : +33 9 53 19 21 90 / Mob : +33 6 03 70 65 46 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
