在 Subversion 存储库中存储文件权限
如何在存储库中存储文件权限？ 一些文件需要是只读的，以阻止第三方程序破坏它，但在检出存储库后，它们被设置为读写。
我在 google 上查找了2005 年的博客文章 表明 Subversion 不存储文件权限。 列出了补丁和挂钩脚本（仅存在一个 url）。 三年后，Subversion 仍然不存储文件权限吗？钩子是解决此问题的唯一方法吗？ （我从来没有做过钩子，而是使用 Subversion 原生的东西。）
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.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
因为之前的回复中还没有完全说明这一点。 但我讨厌复活僵尸线程。
由于添加对 SVN 的权限支持必须适应多个操作系统和权限类型、NFS、POSIX、ARWED 和 RACF，
这将使 SVN 变得臃肿，可能与 NFS 和 POSIX 等冲突的权限类型发生冲突，或者打开可能的漏洞利用/安全漏洞。
有几种解决方法。
预提交、后提交、开始提交是更常用的，并且是 Subversion 系统的一部分。
但将允许您使用您喜欢的任何编程语言来控制权限。
我实现的系统就是我所说的打包程序，它验证工作副本的已提交文件，然后解析元数据文件，其中列出了文件/文件夹所需的默认权限，以及您希望对它们进行的任何更改。
您还可以对此进行扩展，并允许诸如自动移动、重命名它们、按类型标记修订（例如 alpha、beta、候选发布版、发布版）等操作，
以及支持客户端签出具有附加权限的存储库文件。 您最好考虑创建软件包的安装程序并将其作为资源提供。
想象一下人们在其存储库中设置了一个可执行文件，并设置了 root 权限：www-user 4777
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.
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
考虑使用
svn lock禁止其他人写入该文件。Consider using
svn lockto disallow others from writing to the file.我们创建了一个批处理文件来为我们执行此操作。 不过更喜欢颠覆中的实际支持......
We created a batch file to do this for us. Would prefer actual support in subversion though...
一种可能的解决方案是编写一个脚本，将其与其余代码一起签入，并作为构建过程的第一步运行。
该脚本运行您的代码库副本并设置某些文件的读取权限。
理想情况下，脚本将从简单的输入文件中读取文件列表。
这将使维护变得容易，并且其他开发人员也可以轻松了解哪些文件被标记为只读。
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.
@morechilli：
我之前的帖子中的 asvn 包装器和 OP 帖子中的博客似乎符合您的建议。 尽管它将权限存储在相应文件的存储库属性中，而不是单个外部文件中。
@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.
我建议使用 mtree 实用程序生成权限映射（FreeBSD 默认情况下有它），将映射存储在存储库中，并且如上所述，运行一个脚本，该脚本将从映射中恢复正确的文件权限，作为创建权限的第一步。构建过程。
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不存储权限。 您唯一的选择是将对 svn 的调用包装在脚本中。 该脚本应使用其参数调用 svn，然后设置权限。 根据您的环境，您可能需要调用脚本svn并调整您的PATH以确保它被调用。我非常喜欢 morechilli 的想法，即将文件列表和权限签入存储库本身。
Graham,
svndoesn't store permissions. Your only option is to wrap your call tosvnin a script. The script should callsvnwith its arguments, then set the permissions afterward. Depending on your environment, you might need to call your scriptsvnand tweak yourPATHto ensure it gets called.I quite like morechilli's idea to have the list of files and permissions checked into the repository itself.
很多答案都说svn不存储文件权限。 这可能是真的，但我只需通过以下步骤就可以解决没有执行权限问题的dll文件：
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:
SVN 中没有存储文件权限的本机方法。
asvn 和 该博客文章中的补丁似乎已经启动（并托管在官方 SVN 存储库上） ），这是一件好事，但我认为他们不会很快在核心版本中进行此类元数据处理。
SVN 有能力处理 符号链接和可执行文件 特别是很长一段时间，但都不能在 Win32 上正常工作。 我不会对另一个这样的不可移植的功能屏住呼吸（尽管在现有的元数据系统之上实现它并不太难。）
我会考虑编写一个 shell 脚本来手动调整文件权限，然后将它在存储库中。
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.
SVN 确实能够将元数据（属性）与文件一起存储。 这些属性基本上只是键/值对，但是有一些特殊的键，例如“svn:executable”，如果文件存在此属性，Subversion 将在检出文件时设置该文件的文件系统的可执行位。 虽然我知道这并不完全是您正在寻找的东西，但这可能就足够了（对我来说）。
行结束符 (svn:eol-style) 和 mime 类型 (svn:mime-type) 还有其他属性。
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).
这是 SVN 补丁的更新链接它可以正确处理 Unix 风格的文件权限。 我已经在 fedora12 上进行了测试，似乎按预期工作：
我刚刚将其保存在 /usr/bin/asvn 中，如果我需要正确处理权限，则使用 asvn 而不是 svn 命令。
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.