在 Subversion 存储库中存储文件权限

Posted 2023-03-14

【中文标题】在 Subversion 存储库中存储文件权限

【英文标题】：Storing file permissions in Subversion repository

【发布时间】：2010-09-08 12:59:28

【问题描述】：

如何将文件权限存储在存储库中？一些文件需要只读以阻止第三方程序将其丢弃，但在签出存储库后，它们被设置为读写。

我在 google 上查找了一个 blog post from 2005，它指出 Subversion 不存储文件权限。列出了补丁和钩子脚本（只有一个 url 仍然存在）。三年后，Subversion 是否仍然不存储文件权限，并且挂钩是解决此问题的唯一方法吗？ （我从来没有做过钩子，而是使用了 Subversion 原生的东西。）

【问题讨论】：

好问题。然而，直到今天，答案仍然是一样的。除了 +x 之外，无法将 chmod 更改为 SVN 文件。如果在 git 中是可能的，我会徘徊

@confiq 在 git 中非常可能。实际上，您可以提交仅修改权限的更改。但是，我不知道如果您将该提交推送到 svn 会发生什么:)

【参考方案1】：

考虑使用svn lock 禁止其他人写入文件。

【参考方案2】：

锁定不能解决这个问题。锁定会阻止其他人编辑文件。这是一个第三方应用程序，它作为构建过程的一部分运行，它试图写入文件 - 更改它 - 这会破坏构建过程。因此，我们需要阻止程序更改文件，这只是将文件标记为只读。我们希望将这些信息保存在存储库中，并通过签入、分支等进行传递。

【参考方案3】：

一种可能的解决方案是编写一个脚本，将其与其余代码一起签入，并作为构建过程的第一步运行。

此脚本运行您的代码库副本并设置某些文件的读取权限。

理想情况下，脚本会从简单的输入文件中读取文件列表。 这将使其他开发人员易于维护，并易于了解哪些文件被标记为只读。

【讨论】：

惊喜：Subversion 似乎在您提交时实际上 更改 权限:(

【参考方案4】：

Graham，svn 不存储权限。您唯一的选择是将您对svn 的调用封装在一个脚本中。该脚本应使用其参数调用svn，然后设置权限。根据您的环境，您可能需要调用您的脚本svn 并调整您的PATH 以确保它被调用。

我非常喜欢 morechilli 将文件列表和权限检查到存储库本身的想法。

【参考方案5】：

我们创建了一个批处理文件来为我们执行此操作。虽然更喜欢颠覆的实际支持......

【参考方案6】：

在 SVN 中没有本地存储文件权限的方法。

该博客文章中的asvn 和the patch 似乎都已启动（并托管在官方 SVN 存储库中），这是一件好事，但我认为它们不会在核心中进行此类元数据处理版本很快。

SVN 能够处理symbolic links 和executables 已经有很长一段时间了，但在Win32 上都不能正常工作。我不会为另一个这样的非便携式功能屏住呼吸（尽管在已经存在的元数据系统之上实现它不会太难。）

我会考虑编写一个 shell 脚本来手动调整文件权限，然后将其放入存储库中。

【讨论】：

asvn 的正式版（截至目前）似乎没有处理工作目录中大量被忽略的文件（它的输出非常嘈杂），这里有一个补丁修复 mail-archives.apache.org/mod_mbox/subversion-dev/201005.mbox/… ;由于某种原因，它仍然没有进入主线回购。

上面的 asvn 链接已更改为：asvn 在遵循上述这些线索之后，我发现了一些可能效果更好的替代方案：http://fsvs.tigris.org/ 和可能：https://trac.dass-it.de/pub/wiki/dasscm

【参考方案7】：

SVN 确实具有将元数据 (properties) 与文件一起存储的能力。属性基本上只是键/值对，但是有一些特殊的键，例如 'svn:executable'，如果文件存在此属性，Subversion 将在检出文件时为该文件设置文件系统的可执行位。虽然我知道这不是您正在寻找的东西，但它可能就足够了（对我来说）。

还有其他属性用于行尾 (svn:eol-style) 和 mime 类型 (svn:mime-type)。

【讨论】：

我不小心投了赞成票，因为它有一个指向原始文档的链接。但我希望我能收回，因为这个答案似乎暗示可以通过这种方式设置读/写文件权限。

【参考方案8】：

@morechilli：

我之前的帖子中的 asvn 包装器和 OP 帖子中的博客似乎符合您的建议。尽管它将权限存储在相应文件的存储库属性中，而不是单个外部文件中。

【参考方案9】：

This 是正确处理 unix 样式文件权限的 SVN 补丁的更新链接。我已经在 fedora12 上进行了测试，并且似乎可以按预期工作：

如果我需要正确处理权限，我只是将其保存在 /usr/bin/asvn 并使用 asvn 而不是 svn 命令。

【讨论】：

似乎也适用于 ubuntu 12.04。但请注意，当您更新沙箱时，如果存储库中有任何文件具有您无权访问的权限或组信息（可能是因为您使用 sudo 创建或更新了它们），那么设置这些权限的过程可能无法重现上次提交的原始工作区，除非您运行：sudo asvn update.

【参考方案10】：

我建议使用 mtree 实用程序生成权限映射（FreeBSD 默认有它），将映射存储在存储库中，并且如上所述，运行一个脚本，该脚本将从映射中恢复正确的文件权限作为第一个构建过程的步骤。

【参考方案11】：

许多答案都表明svn不存储文件权限。这可能是真的，但我可以通过以下步骤解决没有执行权限问题的 dll 文件：

chmod 755 badpermission.dll mv badpermission.dll ../ svn 更新 svn rm badpermission.dll svn commit badpermission.dll -m "Remove dll to fix permissions" mv ../badpermission.dll . svn 添加 badpermission.dll svn commit badpermission.dll -m "重新添加 dll 以修复权限" rm badpermission.dll svn 更新 badpermission.dll 以执行权限返回

【讨论】：

虽然上述方法几乎可以工作，但它肯定比简单地运行已经存在多年的svn propset svn:executable ON your-pesky-file.ext 效率低（这是google.com/search?q=svn+chmod 搜索的第一次命中。）我说差不多，因为在开头chmod 755 中删除组写入权限不会“坚持”。你可能认为它在你的本地沙箱中是这样，但尝试重新检查文件，你会看到 SVN 设置了 g+w。

【参考方案12】：

因为这在之前的回复中还没有完全说明。不过我讨厌复活僵尸线程。

由于添加对 SVN 的权限支持必须适应多种操作系统和权限类型、NFS、POSIX、ARWED 和 RACF

这会使 SVN 变得臃肿，可能会与 NFS 和 POSIX 等冲突的权限类型发生冲突，或者打开可能的漏洞利用/安全漏洞。

有几种解决方法。 pre-commit、post-commit、start-commit 是比较常用的，并且是 Subversion 系统的一部分。 但将允许您使用您喜欢的任何编程语言来控制权限。

我实现的系统是我所谓的打包程序，它验证工作副本的提交文件，然后解析元数据文件，其中列出了文件/文件夹所需的默认权限，以及您还希望对它们进行的任何更改.

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

您还可以对此进行扩展，并允许自动移动、重命名、按类型标记修订，例如 alpha、beta、候选发布、发布

至于支持客户端签出您的存储库文件并附加权限。您最好考虑创建软件包的安装程序并将其作为资源提供。

想象人们设置他们的存储库，其中设置了一个可执行文件，权限为 root:www-user 4777