我有一个巨大的项目。
我需要创建一个分支 - 这将是项目的版本 2，但我还需要保留主干并将其与分支 1 并行更改，作为版本 1 的错误修复。
我需要合并来自主干的错误修复到分支 1，同时向分支添加新功能。
最后，我需要将所有更改合并回主干并从中创建新标签。
所以我需要版本 1 的错误修复，版本 2 的新分支，当然还有合并版本 2 中的错误修复。
我正在使用 svn，但 svn 总是出现问题。我无法在没有冲突的情况下合并任何东西。
有人可以给我建议该怎么做吗？
问候
I have a huge project.
I need to make a branch - this will be version 2 of the project, but I also need to keep the trunk and change it in parallel with the branch 1 as bug fix to the version 1.
I need to merge bug fixes from the trunk to the branch 1 while adding new features to the branch.
At the end I need to merge all changes back in the trunk and make new tag from it.
So I need bug fix for version 1, new branch for version 2 and of course merging bug fixes in the version 2.
I am using svn but the svn makes problems all the time. I cannot merge anything without conflicts.
Can someone give me an advice what to do?
Regards
发布评论
评论（4）
为了向旧版本提供错误修复而创建分支称为 发布分支。您应该在主干上开发错误修复（因为它们需要进入所有新版本，对吧？）。从那里您可以将它们合并回仍然受支持的版本。这意味着当版本 1 不再受支持时，您将停止将错误修复合并回该版本。请参阅文档了解更多信息。
如果主干中的错误修复无法合并到分支，解决方案是创建一个“向后移植分支”。在这里，您可以部分合并来自主干的修复，如果代码差异太大，则部分重写相同的修复。还建议记录您通常为解决问题而执行的合并，因此合并跟踪可以帮助您了解问题是否已解决。
如果您要修复 /branches/1.2.x，Subversion 项目使用的命名约定是创建一个名为 1.2.xr[REVNUM] 的向后移植分支，其中 REVNUM 表示您要向后移植的修订版，或 1.2.x-issue[ ISSUENUM]，其中 ISSUENUM 表示您正在修复的问题。
创建反向移植修复后，您可以将其合并到版本中，
重新集成分支后，应删除分支。
Creating a branch for the purpose of providing bugfixes to older version is called a release branch. You should develop the bug fixes on trunk (because they need to go in all new versions right?). From there you merge them back to the versions that are still supported. That means that when version 1 is no longer supported, you stop merging bug fixes back to it. See the documentation for more info.
If a bugfix in trunk cannot be merged to the branch(es), the solution is to create a 'backport branch'. Here you either partially merge the fix from trunk, partially rewrite the same fix if the code is too different. It's also suggested to record the merges you would normally perform to fix the problem, so merge tracking helps you see wether or not the problem was fixed.
If you're fixing /branches/1.2.x, the naming convention the Subversion project uses is to create a backport branch called 1.2.x-r[REVNUM], where REVNUM indicates the revision you're backporting, or 1.2.x-issue[ISSUENUM], where ISSUENUM indicates the issue you're fixing.
When you're done creating the backport fix, you can merge it to the release with
After reintegrating the branch, the branch should be deleted.
您应该首先为您的版本 1 创建一个“标签”，该版本是您产品的发布版本。该项目的版本 2 将成为主干的延续，而不是版本 2 的分支。您需要创建分支的唯一原因是对（发布的）版本 1 进行错误修复。您为新版本所做的所有操作都将在主干上完成，除非您有理由不这样做。
You should first have created a "tag" for your version 1, which is a released version of your product. Version 2 of the project will then be a continuation of the trunk, not a version 2 branch. The only reason you would need to create a branch is to make bug fixes to the (relesed) version 1. Everything you do for the new version would be done at the trunk, unless you have reasons not to.
首先也是最重要的，我建议您查看 SVN 文档，按照 @SanderRijken 的建议，看看有哪些功能和发布分支。
但根据你的问题的声音，我认为你的主要问题是不同的。也就是说，根本没有合并是“有效的”（即所有合并都会产生您意想不到的冲突）。那么也许您可以确切地详细说明您正在做什么（例如发布您用于合并的命令）？
First and foremost I suggest you have a look at the SVN documentation as suggested by @SanderRijken and see what feature and release branches are.
But by the sound of your question I assume your main problem is a different one. Namely that no merge at all is "working" (i.e. all give conflicts where you would not expect them). So maybe you could elaborate what you are doing exactly (like post the command you use for merging)?
将主干的更改合并到分支后，我发现最好使用 2-URL 合并将分支合并回主干。据我了解 --reintegrate 它只是 2-URL 合并的一种更简单的语法，有时 失败（尽管我上次在版本 1.5 中使用了 reintegrate）。
其中 mergedRev 是您上次将主干合并到分支时的修订版本。
如果您使用简单的合并指令，则从主干合并到分支的所有更改都将被视为需要在合并回来时添加到主干的更改。 2-URL 合并中的第一个 url 告诉 svn 哪些更改来自主干。这应该会大大减少合并期间的冲突。
至于您的存储库的结构，我可以建议来自 ariejan.net
博客条目的博客条目（见下文，因为我只允许在我的帖子中使用一个链接）：ariejan.net/2006/11/24/svn-how -构建您的存储库/
After merging changes from the trunk into a branch I find it best to merge the branch back into the trunk using the 2-URL merge. As far as I understand --reintegrate it is just a simpler syntax for the 2-URL merge which sometime fails (though I last used reintegrate in version 1.5).
Where mergedRev is the revision when you last merged the trunk into the branch.
If you use the simple merge instruction all changed that you merged from the trunk into the branch will be seen as changed that need to be added to the trunk when merging back. The first url in the 2-URL merge tells svn which changes came from the trunk. This should greatly reduce the conflicts during merging.
As for the structure of your repository I can suggest a blog entry (see below since I'm only allowed to use one link in my post) from ariejan.net
blog entry: ariejan.net/2006/11/24/svn-how-to-structure-your-repository/