Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Bart, > After checking one of the files out to a windows client, > changing it and committing it back to the repository the > permission line in the rcs-file for the new version was set > to 666. Which version ? What is your environment ? http://march-hare.com/cvspro/faq/faq2.asp#2z This article discusses the various problems with trying to detect read/write/execute bits and the environment variables that affect it (I just noticed that a lot of the comments are marked as private so you possibly wont be able to read much of it, but hopefully enough to get the gist): http://customer.march-hare.com/webtools/bugzilla/ttshow_bug.cgi?id=4732& tt=1 Basically if you are using an NTFS file system on the windows client and do NOT have CYGWIN installed then all should work OK. If you checkout onto a FAT filesystem then we've got nowhere to store the permissions and if you have some CYGWIN environment variables set then they can break the default handling (by attempting to preserve cygwin rules). Finally a NAS will most likely be FAT causing the execute bit to be lost or a SAN may just not work properly (which is what bug4732 covers) resulting in a rubbish result. Experimenting with the same workarounds as listed in bug4732 for a SAN should eventually get you the right result. Implementing an (optional?) rule in CVSNT where a non-force commit causes the execute bit to be set on new revisions if it was previously set on the checked out revision (regardless of the eecute bit on the actual file in the sandbox) would be a way around it but would be a significant deviation from past behaviour, and quite possibly a fair bit of work. Regards, Arthur