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.
Oliver, > we have a mixed environment and thus both Windows and Linux > clients commit to the CVS repo in question. The server is > running good old CVS, not CVSNT (apparently no way to upgrade > :-( ...). I suppose security and audit compliance means nothing to your orgnaisation, let alone productivity... Certainly upgrading legacy systems has a cost and before such upgrades are embarked upon the benefits need to be documented and weighed against the costs - however if there are clear benefits in upgrading and clear costs to continuing to use old insecure unproductive software then those who argue for the status quo need to be prepared to pay for those costs. Suggest deducting the costs of lost productivity and the costs of performing manual audits from the sysadmins wage and you'll see a different result... 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). > Anyway, it appears that on my machine (Windows 2003) the > CVSNT client included in TortoiseCVS takes away the right to > execute a file on occasion (this is reflected by the x bits > on that file in the repo itself), which is highly annoying > with scripts (which always need this, be it .cmd or .pl). The 'x' bit is the mode not the ACL. 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. 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. 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. > Any chance to inhibit this behavior through configuration? > I'd prefer if the client wouldn't meddle with my ACLs and > simply inherit from the parent folder. The 'mode' of the file is not an ACL by any definition, please do not confuse terms... Regards, Arthur