如果您使用 subversion 将主干中的一组特定修订合并到分支中，会发生什么？
如果我在主干中对 3 个不同的文件进行更改，分别为修订版 40、45 和 47，其中自修订版 15 以来这些文件都没有更改，那么如何将这些修订合并到分支中（在修订版 30 中进行，并且自修订版以来未更改） ）这样我就可以得到每个相应文件的 rev 15 和 rev 40、45 和 47 之间的更改？
在中间修订版中进行了其他更改（显然），但它们不会影响相关文件，并且我不希望这些更改显示在分支中。
If I make changes in the trunk to 3 different files, say revisions 40, 45, and 47 respectively, where none of those files have changed since revision 15, how can I merge those revisions into the branch (made at revision 30 and unchanged since) so that I get just the changes between rev 15 and rev 40, 45, and 47 for each of the respective files?
Other changes have been made at the in-between revisions(obviously) but they do not affect the files in question, and I do not want those changes to show up in the branch.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您只在这些提交中对这些文件进行了更改，那么只需继续合并这些修订号即可。 如果在这些提交中更改了其他文件，并且您不希望进行这些更改，我可能会继续进行合并，然后恢复对您不想修改的文件的更改，然后进行提交。
If you only made changes to those files in those commits, then just go ahead and merge those revision numbers. If other files were changed in those commits, and you do not want those changes, I would probably go ahead and do the merge anyway, and then revert changes on the files you do not want modified, then do the commit.
在我们的系统中，我们不断地进行这样的合并。 在大多数情况下，一切都很好。
您可以对所有三个修订版进行合并，只要更改不相互依赖，就可以了。
使用 TortoiseSVN 变得很容易，因为您只需指定
40,45,47作为范围匹配即可。 否则，只需为每个修订语句发出单独的 svn merge ，它就会将其全部整合在一起。如果您未拉入的更改影响相同的行，则会出现合并冲突。 这是最好的情况，因为这意味着您需要立即查看它以解决冲突。 然而，与往常一样，仅仅因为它不是冲突，并不意味着您不会在编译/运行时遇到一些逻辑错误。
我个人每周会做数百次这样的事情，所有这些都使用自动化脚本。 由于我们的代码结构（一个大型存储库，其中大多数更改不会影响相同的文件），我们每周只会遇到一些冲突。
In our system we do merges like this constantly. For the most part everything works great.
You can run a merge on all three revisions and as long as the changes are not interdependent you are all good.
Using TortoiseSVN makes it easy because you can simply specify
40,45,47as the range match. Otherwise just issue a separatesvn mergefor each revision statements and it will pull it all together.If the changes you are not pulling in affect the same lines, you will get a merge conflict. That is the best case scenario, because it means you immediately need to look at it to resolve the conflict. However, as always, just because it wasn't a conflict, doesn't mean you won't get some logic error at compile/run times.
I personally do several hundred of these a week, all with an automated script. Because of how our code is structured (a large repository where most changes are not affecting the same files) we only get a few conflicts a week.