[cvsnt] losing execute permission after commit from windows client

[Arthur Barrett]

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