在预提交脚本中，是否有可能(如果是，如何(识别源自svn merge的提交？
svnlook changed ...显示已更改的文件，但不区分合并和手动编辑。
理想情况下，我还想区分标准merge和merge --reintegrate。
背景：
我正在探索使用预提交钩子来为我们的项目强制执行 SVN 使用策略的可能性。
其中一个策略指出，某些目录(例如/trunk(不应直接修改，而只能通过功能分支的重新整合来更改。因此，预提交脚本将拒绝对这些目录所做的所有更改，但分支重新集成除外。
有什么想法吗？
更新：
我已经探索了svnlook命令，我最接近的是检测和分析对目录svn:mergeinfo属性的更改。这种方法有一些缺点：
-
svnlook可以标记属性中的更改，但不能标记更改的属性。(需要与先前修订版的proplist差异( - 通过检查
svn:mergeinfo的变化，可以检测到svn merge是否运行。但是，无法确定提交是否纯粹是合并的结果。合并后手动进行的更改将无法检测到。(相关文章：将事务树与另一个路径/修订版进行比较(
Subversion 不强制仅合并提交
如果我有权访问分支，我可以在合并后和提交之前执行任何操作
颠覆合并也发生在客户端
许多代码存储库工具将在服务器上合并。 即强制你只将补丁从一个流移动到另一个流
我最终采用了一个不理想的解决方案，即检测更改树顶部目录中svn:mergeinfo属性中的更改(在 SVNTransaction.is_merge_operation() 中实现(。
我们无法区分仅合并提交和还包含其他更改的提交。这意味着，如果与合并一起提交，则该树下发生的所有更改都不会被检测到。一个可能的解决方案可能是将事务树与合并源进行比较，但我还没有弄清楚如何实现这一目标(这也需要考虑由于冲突解决而导致的变化(。
它也无法区分merge和merge --reintegrate。
其他限制包括对svn:mergeinfo的依赖，这是用户可修改的，并且在旧版本的Subversion中不使用。
有问题的提交脚本旨在温和地提醒标记违反项目准则的提交，而不是访问控制机制，因此上面列出的限制不会阻碍。但是，我仍在寻找改进。欢迎提出意见和进一步建议。