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.
>> Could some please help clarify the last two paragraphs of this thread. I am >> also trying > >to commit shell scripts that are executable from a Linux system onto CVSNT. > >I tried > >changing the permissions on the file to include executable and then > >committed the file. > >Not only did it not retain the settings on the server, the local copy lost > >the setting. Is > >this normal? Is there any way around this? > >This might be a side effect of preventing null-delta commits. I assume >here that you didn't get a message from CVS indicating the new revision >number, right? > >Try doing that again with "cvs ci -f" instead, to force it to commit the >file. I'm not certain of the effect of that flag since I've never used it. > >If that doesn't cause the file to be committed, try making a minor >change to the file and marking it +x again, then committing. > >Also note that if you checkout and commit that file from a Win32 >platform, it will loose the execute flag again (if I understand the >previous conversations). > >Regards, >Glen Starrett I have tried using cvs -w commit -f file1 to force a commit after changing the permissions to include executable. I also tried editing the shell script and touching the files that are binary and then committing the file. In both ways the commit caused the files to loose the executable setting after they were committed. After each try I deleted all the files and checked them out again and they did not have the setting set. So, the commit command causes the file to loose it's exactable setting and the checkout does not restore it. I have done all the commands through the command line, no gui. Could CVS be defaulting to read only files somehow and resetting the permissions because of that? Any other ideas greatly welcome. Thanks, Curt