Svn 在预提交脚本中检测分支重新整合或合并

在预提交脚本中，是否可以（如果可以，如何）识别源自

svn合并的提交

svnlook changed…
显示已更改的文件，但不区分合并和手动编辑

理想情况下，我还想区分标准的
合并
和
合并--重新整合

背景：
我正在探索使用预提交挂钩为我们的项目强制执行SVN使用策略的可能性

其中一项政策规定，某些目录（如
/trunk
）不应直接修改，而只能通过重新整合功能分支进行更改。因此，预提交脚本将拒绝对这些目录所做的除分支重新整合之外的所有更改

有什么想法吗


更新：
我已经研究了
svnlook
命令，最接近的方法是检测并解析对目录的
svn:mergeinfo
属性的更改。这种方法有一些缺点：

svnlook
可以标记属性的更改，但不能标记更改了哪个属性。（需要与先前版本的
proplist
进行区分）
通过检查
svn:mergeinfo
中的更改，可以检测到运行了
svn merge
。但是，无法确定提交是否纯粹是合并的结果。合并后手动进行的更改将无法检测到。（相关职位：）
不幸的是，subversion不强制仅合并提交

如果我有权访问分支，我可以在合并之后和提交之前执行任何操作

subversion合并也发生在客户端

许多代码存储库工具将在服务器上合并。i、 e.强制执行只将修补程序从一个流移动到另一个流
我最终求助于一种非理想的解决方案，即检测更改树顶部目录中的
svn:mergeinfo
属性中的更改（在中实现）

我们无法区分仅合并提交和还包含其他更改的提交。这意味着，如果与合并一起提交，则在该树下发生的所有更改都不会被检测到。一个可能的解决方案可能是根据合并源区分事务树，但是（这还需要考虑冲突解决方案导致的更改）

它也不能区分
合并
和
合并--重新整合

其他限制包括依赖于
svn:mergeinfo
，这是用户可修改的，在较旧版本的subversion中不使用

讨论中的提交脚本旨在温和地提醒您标记违反项目指导原则的提交，而不是访问控制机制，因此上面列出的限制并不是一个障碍。然而，我仍然在寻找改进欢迎评论和进一步建议。
您需要区分重返社会和定期合并吗？@lvaroG.Vicario理想情况下，是的。但是我可以满足于简单地检测任何类型的合并。我不认为解析
svn:mergeinfo
是脆弱的：这个属性是Subversion用来跟踪更改的机制。但是，我不确定
--replication
选项是否对修订属性有任何直接影响。“对不起，我帮不上什么忙了。”“阿尔瓦罗。代理”说得好。不幸的是，光看
svn:mergeinfo
是不够的。请参阅上面的更新。