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.
Arthur, thanks for your reply. > I suppose security and audit compliance means nothing to your > orgnaisation, let alone productivity... I suppose, I'd be the wrong person to ask for this. Also, it's not "my" organization, so I have no real leverage in changing it. > Specifically by not using CVSNT server you are missing out on: user > defined change sets, merge tracking, auto merges (mergepoint), real ACLs > (including branches), failsafe audit, commit identifiers (some people > call this atomicity), secure repositories (aliases, mode, dynamic > protocol disabling etc, chroot jail etc). I'll suggest it, but as I mentioned it is not up to me. > The 'x' bit is the mode not the ACL. I am aware of this. When mentioning ACL I am talking about the NT notion of an ACL, not whatever CVSNT has implemented as ACLs. > CVS server stores the 'mode' of the checked out file in the 'mode' of > the RCS file (ie: to have build.sh as executable then build.sh,v needs > to be executable) - which some sysadmins see as a security risk - hence > why CVSNT Server stores the executable bit in the RCS file itself as an > attribute. An even better reason to urge people in the company to upgrade to CVSNT. Let's see whether these arguments help. > Every CVS client (CVS, CVSNT etc) sends the 'mode' of the file to the > server with each commit - however on windows there is no 'execute bit' > (executable files are defined based on the extension or the environment > variable PATHEXT) - so on windows the 'execute' bit is always removed on > commit. Wouldn't that mean that checking it out again causes the script to become non-executable after checking it out anew? Due to this mapping between NT ACLs and the file mode on the CVS server/RCS file? > With CVSNT client you could try experimenting with "set CYGWIN=ntsec" or > "set CVSNT=ntsec" to see if some combination of ntsec, ntea, nontsec, > nontea works better. Thanks, will try that. > The 'mode' of the file is not an ACL by any definition, please do not > confuse terms... I am aware of that, but apparently some kind of mapping between NT ACLs and the file mode *is* going on. And in that sense I definitely meant ACLs ;) Thanks again for the swift and detailed reply, // Oliver PS: Re-sent through the list, because I replied to Arthur only accidentally.