Avoid having subversion modify Linux file permissions.

the owner of the files will be set to the user that is running the svn command because of how it implements the underlying up command - it removes and replaces files that are updated, which will cause the ownership to 'change' to the relevant user. The only way to prevent this is to actually perform the svn up as the user that the files are supposed to be owned as. If you want to ensure that they're owned by a particular user, then run the command as that user.

With regards to the permissions, svn is only obeying the umask settings of the account - it's probably something like 066 - in order to ensure that the file is inaccessible to group and other accounts, you need to issue 'umask 077' before performing the svn up, this ensures that the files are only accessible to the user account issuing the command.

I'd pay attention to the security issue of deploying the subversion data into the web server unless the .svn directories are secured.

You can store properties on a file in Subversion (see http://svnbook.red-bean.com/en/1.0/ch07s02.html). You're particularly interested in the svn:executable property, which will make sure that the executable permission is stored.

There's no general way to do this for all permissions, though. Subversion doesn't store ownership either - it assumes that, if you check something out, you own it.

You can solve this. Use setgid.

1. You have apache:apache running the server

2. Set group permission on all files and directories. The server will read files by it's group

3. Set setgid on all directories - only on directories: setting this on files has a different function

   Example ('2' is setgid):

   chmod 2750

4. Make apache the group of all directories

What happens is

• New files and directories created by any account will be owned by the apache group

• New directories will inherit the setgid and thus preserve the structure without any effort

See https://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories