Subversion 中，除了基于路径的访问控制之外，还有什么替代方法吗？
我正在处理一个包含受 ITAR 约束的文件的存储库。几个团队将有权访问存储库，但其中一些团队甚至不允许查看 ITAR 敏感数据，因此我们在这里讨论的是读取访问权限，而不仅仅是提交访问权限。
现在我有几种选择来处理这个问题。
第一种是简单地列出所有具有访问限制的文件。这样做的问题是，我们需要知道文件名是什么，然后才能将其添加到身份验证文件中。因此，开发人员创建一个ITAR敏感文件，通过电子邮件将完整路径发送给svn管理员，然后将其添加到身份验证文件中。只有这样，开发人员才能实际添加和提交文件。
另一种解决方案是在顶层有两个目录，例如 general 和 mil ，具有相同的子目录。这样，所有敏感文件都会进入mil，所有其他文件都会进入general。这给了我一个简短而甜美的身份验证文件，但缺点是，如果文件变得对 ITAR 敏感，则需要将其从一棵树移动到另一棵树。我们可以使用它，但这不是最佳的。
我想要的是基于属性的访问控制。如果我们可以添加一个属性，例如mil或itar:reason到文件中并基于此限制访问，那将是理想的。开发人员可以在首次提交之前或文件变得敏感时添加属性。但是，除非我错过了，否则这是不可能的。
那么有没有人看到这个问题的其他解决方案？
我不确定即使是属性也能解决问题，因为它们是版本化的。 因此，如果您添加文件并忘记立即设置该属性，聪明的用户可以检索该文件的早期版本。 您必须愿意从转储文件中清除有问题的数据，这当然需要一些停机时间。
无论如何，如果有人犯了错误并将文件放在错误的位置、错误的存储库或具有错误的属性，您几乎会遇到任何问题。 如果您知道 ITAR 文件的某些属性，那么您可以编写一个钩子来防止它们被放入存储库的错误部分。 然后，您可以查看基于"已知敏感"路径甚至单独的存储库和外部路径的解决方案。
否则，您可以考虑在Apache前面放置一个代理，该代理知道所有敏感文件，无论它们何时被指定为敏感文件，并将它们从未经授权的用户的流量中清除。 这是一个棘手的问题。
Subversion 中基于路径的访问控制的替代方案
我不知道基于文件属性的读取访问限制。
缺点是，如果文件变得对ITAR敏感，则需要将其从一个树移动到另一个树。
这是无法避免的，或者如果没有"竞争条件"就很容易自动化：你可以在该文件上设置一个属性，并让一个 cron 作业将通常找到的任何文件移动到 mil，但这意味着在该 cron 作业运行之前，任何有权访问 mil 的人都可以查看该文件。
在两个顶部文件夹（类似于分支）之间按需移动更好。
最接近自动化移动的方法是：
- 设置文件的属性
- 运行一个
svn post-revprop钩子，它将检测到该特殊属性并为您移动。