问题描述
按照标准惯例，我有一个用于功能开发的svn干线，以及一个用于构建版本的分支分支.分支是使用maven版本插件创建的，该插件也用于创建版本.碰巧的是，偶尔的错误将在分支上修复，并且这些更改需要重新合并到主干中.为了不遗漏任何更改，我希望能够简单地将整个分支合并回主干.
following standard practice, I have an svn trunk for feature development, and a forked-off branch for building releases. The branch has been created using the maven release plugin, which is also used for creating releases. As it happens, the occasional bug will be fixed on the branch, and those changes need to be merged back into the trunk. To not miss any changes, I'd like to be able to simply merge the complete branch back into the trunk.
现在我的问题是，由于发行插件增加了版本号，项目/依赖版本在分支和主干中出现了分歧，所以我在所有poms中都遇到了很多冲突.有没有人知道如何重组分支创建，我的pom或发布以避免这些合并冲突?
Now my problem is that I get numerous conflicts in all my poms because project/dependency versions diverged in the branch and in the trunk, due to the release plugin incrementing version numbers. Does anybody have an idea how to restructure branch creation, my poms or releasing to avoid those merge conflicts?
推荐答案
这是通过这种方式一起使用Maven POM和Subversion分支所固有的.您有几种选择.
This is inherent in using Maven POMs and Subversion branches together in this way. You have a few options.
- 请从SVN中的修订版本开始进行合并，以避免提交会影响快照.有时更简单但不是理想的合并方式，但最终仍会发生冲突
- 检查冲突，如果仅有POM更改，请使用
mine-conflict(mc)作为选项.如果您对此有信心，可以使用SVN的--accept mine-conflict - 允许它们被错误地合并，然后使用版本的插件通过
versions:set重置版本.
- do your merges starting with a revision in SVN to avoid the commit that bumped the snapshot. Sometimes simpler, but not the ideal way to merge and can still end up with conflicts
- check the conflicts and use
mine-conflict(mc) as the option if POM changes are the only ones. If you're confident of this, you can use SVN's--accept mine-conflict - allow them to be incorrectly merged and use the Version's plugin to reset the version afterwards with
versions:set
这篇关于由于poms中版本的更改，合并来自maven release分支的更改会产生冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！