Storing file permissions in Subversion repository

Question

How do you store file permissions in a repository? A few files need to be read-only to stop a third party program from trashing it but after checking out of the repository they are set to read-write.

I looked on google and found a blog post from 2005 that states that Subversion doesn't store file-permissions. There are patches and hook-scripts listed (only one url still exists). Three years later does Subversion still not store file permissions and are hooks the only way to go about this? (I've never done hooks and rather use something that is native to Subversion.)

Answer 1

Consider using svn lock to disallow others from writing to the file.

Answer 2

Locking would not solve this problem. Locking stops others from editing the file. This is a third party application which gets run as part of the build process that tries to write to a file - changing it - which breaks the build process. Therefore we need to stop the program from changing the file which is simply marking the file read-only. We would like that information to be held in the repository and carried across checkins, branches, etc.

Answer 3

One possible solution would be to write a script that you check in with the rest of your code and which is run as the first step of your build process.

This script runs through your copy of the codebase and sets read permissions on certain files.

Ideally the script would read the list of files from a simple input file. This would make it easy to maintain and easy for other developers to understand which files get marked as read-only.

Answer 4

Graham, svn doesn't store permissions. Your only option is to wrap your call to svn in a script. The script should call svn with its arguments, then set the permissions afterward. Depending on your environment, you might need to call your script svn and tweak your PATH to ensure it gets called.

I quite like morechilli's idea to have the list of files and permissions checked into the repository itself.

Answer 5

We created a batch file to do this for us. Would prefer actual support in subversion though...

Answer 6

There's no native way to store file permissions in SVN.

Both asvn and the patch from that blog post seem to be up (and hosted on the official SVN repository), and that's a good thing, but I don't think they will have such metadata handling in the core version any time soon.

SVN has had the ability to handle symbolic links and executables specially for a long while, but neither work properly on Win32. I wouldn't hold my breath for another such non-portable feature (though it wouldn't be too hard to implement on top of the already existing metadata system.)

I would consider writing a shell script to manually adjust file permissions, then putting it in the repository.

Answer 7

SVN does have the capability of storing metadata (properties) along with a file. The properties are basically just key/value pairs, however there are some special keys like the 'svn:executable', if this property exists for a file, Subversion will set the filesystem's executable bit for that file when checking the file out. While I know this is not exactly what you are looking for it might just be enough (was for me).

There are other properties for line ending (svn:eol-style) and mime type(svn:mime-type).

Answer 8

@morechilli:

The asvn wrapper from my earlier post and the blog in the OP's post seems to do what you're suggesting. Though it stores the permissions in the corresponding files' repository properties as opposed to a single external file.

Answer 9

This is the updated link for SVN patch which handles unix style file permissions correctly. I have tested out on fedora12 and seems to work as expected:

I just saved it /usr/bin/asvn and use asvn instead of svn command if i need permissions handled correctly.

Answer 10

I would recommend to generate permissions map using mtree utility (FreeBSD has it by default), store the map in the repository, and, as was mentioned above, run a script that would restore proper file permissions from the map as the first step of the build process.