12

在预提交脚本中，是否有可能（如果有，如何）识别源自svn merge?

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

理想情况下，我还想区分标准merge和merge --reintegrate.

背景：

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

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

有任何想法吗？

更新：

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

  1. svnlook可以标记属性更改，但不能标记更改了哪个属性。proplist（需要与先前版本的差异）
  2. 通过检查 中的更改svn:mergeinfo，可以检测到svn merge已运行。但是，无法确定提交是否纯粹是合并的结果。合并后手动进行的更改将不会被检测到。（相关文章：Diff transaction tree against another path/revision）
4

2 回答 2

2

不幸的是颠覆不强制合并只提交

如果我可以访问分支，我可以在合并之后和提交之前做任何事情

颠覆合并也发生在客户端

许多代码存储库工具将在服务器上合并。即强制你只是将补丁从一个流移动到另一个流

于 2012-05-04T16:29:52.377 回答
2

我最终采用了一个非理想的解决方案，即检测svn:mergeinfo更改树顶层目录中的属性更改（在 中实现SVNTransaction.is_merge_operation()）。

我们无法区分仅合并提交和还包含其他更改的提交。这意味着如果与合并一起提交，则该树下发生的所有更改都将不会被检测到。一个可能的解决方案可能是将事务树与合并源进行比较，但我还没有弄清楚如何实现这一点（这也需要考虑到冲突解决导致的变化）。

它也不能区分 amerge和 a merge --reintegrate。

其他限制包括用户可修改的依赖，svn:mergeinfo并且不用于旧版本的颠覆。

有问题的提交脚本旨在温和地提醒您标记违反项目指南而不是访问控制机制的提交，因此上面列出的限制并不是一个阻碍。但是，我仍在寻找改进。欢迎评论和进一步的建议。

于 2012-12-14T17:04:45.857 回答