Storing file permissions in Subversion repository

StackOverflow https://stackoverflow.com/questions/56149

  •  09-06-2019
  •  | 
  •  

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.)

Was it helpful?

Solution

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.

OTHER TIPS

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).

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.

Since this wasn't fully said in previous responses yet. I hate to resurrect zombied threads though.

Since adding permission support for SVN would have to accommodate multiple OS's and permission types, NFS, POSIX, ARWED, and RACF

This would make SVN bloated, possibly clash with conflicting permission types like NFS and POSIX, or open up possible exploits/security vulnerabilities.

There are a couple of workarounds. pre-commit, post-commit, start-commit are the more commonly used, and are a part of the Subversion system. But will allow you to control the permissions with what ever programming language you like.

The system I implemented is what I call a packager, that validates the committed files of the working copy, then parses a metadata file, which lists out the default permissions desired for files/folders, and any changes to them you also desire.

Owner, Group, Folders, Files
default: <user> www-user 750 640
/path/to/file: <user> non-www 770 770
/path/to/file2: <user> <user> 700 700

You can also expand upon this and allow things such as automated moving, renaming them, tagging revision by types, like alpha, beta, release candidate, release

As far as supporting clients to checkout your repository files with permissions attached to them. You are better off looking into creating an installer of your package and offering that as a resource.

Imagine people setting their repositories with an executable in it set with permissions of root:www-user 4777

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.

Many answers have stated that svn does not store file permissions. This may be true, but I was able to solve a dll file without execute permissions problem simply by these steps:

  1. chmod 755 badpermission.dll
  2. mv badpermission.dll ../
  3. svn update
  4. svn rm badpermission.dll
  5. svn commit badpermission.dll -m "Remove dll to fix permissions"
  6. mv ../badpermission.dll .
  7. svn add badpermission.dll
  8. svn commit badpermission.dll -m "Add the dll back to fix permissions"
  9. rm badpermission.dll
  10. svn update
  11. badpermission.dll comes back with execute permissions

@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.

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.

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.

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.

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

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

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top