如何验证代码审查的补丁文件是否正是提交到 SVN 存储库的内容
我们有一个代码审查流程，开发人员向团队发送包含其更改的补丁文件。审阅后，他被指示提交或进行更改并重新发送。
我们如何确保已“提交”的内容正是已“批准”的内容 - 即，如果他在未经批准的情况下进行后续更改并提交了这些更改，我如何检测这些更改？
我最后有原始的“补丁文件”，但是：
- 如何在两个提交的版本之间“生成”类似的内容以及
- 比较这两个文件是否可行？
We have a code review process in place where a developer sends out a patch file with his changes to the team. After reviewing it, he is instructed to commit or make changes and resend.
How can we ensure that what has been "committed" is exactly what has been "approved" - i.e., if he makes subsequent changes without approval and commits those, how can I detect those?
I have the original 'patch file' at my end, but:
- How can I 'generate' something similar between the two committed versions and
- Is it viable to compare those two files?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
最简单的解决方案是将此类补丁放入分支，这意味着开发人员将签入分支上的代码。审阅者可以检查代码并将代码合并回特定的集成行。这可以确保签入的代码与已检查的代码完全相同。此外，这种方法的优点是所提出的建议也将记录在版本控制中。
The simplest solution would be to put such patches to a branch which mean the developer will check in the code on the branch. Than a reviewer can check the code and merge the code back to a particular integration line. This makes sure the code checked in is exactly what has been checked. Furthermore this approach has the advanctage the suggestion which have been made will be documented in the version control as well.
我猜您可以通过在旧版本上应用补丁，然后将其与最新版本的代码进行比较来找出差异来做到这一点。
您可以为此使用 svn diff 。
您可能想看看这个答案： 当使用 svn cp 或 svn mv 时，如何使 svn diff 生成补丁将应用的文件？
I am guessing you could do this by applying the patch on the old revision and then comparing the same against the latest version of code for difference.
You could use svn diff for this.
You probably wanna take a look at this answer: How to make svn diff produce file that patch would apply, when svn cp or svn mv was used?
审阅者也应该是提交者，以确保他提交的内容与他审阅和批准的内容相同。
Reviewer should be a committer as well to make sure he commits the same he reviewed and approved.
最简单的方法是审阅者提交他批准的更改。我见过一些老式团队（不久前），其中只有项目经理才能提交到生产存储库。问题是，由于他必须提交太多的东西，所以他没有真正检查任何东西，所以这有点毫无意义。
The easiest way is that The reviewer commit the changes he approved. I've seen some old fashion team (a while ago) where only the project manager could commit to production repository. The thing is, as he has to commit too much stuff he didn't really check anything so that was a bit pointless.