svn：合并工作流程中的细微差别
我们有一个带有主干的存储库、偶尔的功能分支和一些持久的开发人员分支（因为我们每个人都在项目的特定领域工作）。
主干由我们的项目经理管理，除了紧急情况外，他是唯一将分支重新集成到主干中的人。重新集成到主干中的操作也是非常明确的事情。我们遇到的麻烦是在我们的分支机构中该怎么做。 （旁注：我们优先使用 TortoiseSVN，而不是命令行。）
我们的开发人员分支已经不同步，在尝试阅读这个问题时，我对工作流程以及这些方法的优点/缺点感到困惑：
按照以下步骤在分支 B 和主干之间进行对称重新同步：
- merge --从 B 重新整合到主干
- merge --从 trunk 重新整合回 B
- merge --从 B 重新整合到主干
- merge --record-only 从 trunk 到 B（如何在 TortoiseSVN 中执行此操作？）
重新集成并重新启动:< /p>
- merge --从 B 重新整合到主干
- 删除B
- 将中继复制到 B 重新开始
单向重新同步从主干到乙：
- 从 trunk 合并到 B
- （根据需要重复，直到重新融入后备箱。）
我们在选项 #1（对称重新同步）方面进展顺利，并且我真的很困惑为什么#2 和#3 似乎是推荐的方法。
谁能解释一下吗？
此外，在分支 B 和 C 之间合并以交换更新而不首先重新合并到主干的正确方法是什么？[我会问单独的问题]
We have a repository with a trunk, occasional feature branches, and some persistent developer branches (because we each work on particular areas of the project).
The trunk is managed by our project manager, and except in emergencies, he's the only one to reintegrate a branch back into the trunk. The reintegrate-into-the-trunk operation is also something that's pretty clear to do. What we are having trouble with is what to do in our branches. (Side note: we use TortoiseSVN in preference to the command line.)
Our developer branches have gotten out of sync, and in trying to read up on the issue, I'm confused about the workflow, and the pluses/minuses of these approaches:
symmetrical resync between branch B and trunk by following these steps:
- merge --reintegrate from B into trunk
- merge --reintegrate from trunk back into B
- merge --reintegrate from B into trunk
- merge --record-only from trunk into B (how do you do this in TortoiseSVN?)
- merge --reintegrate from B into trunk
- delete B
- copy trunk to B to start anew
one-way resync from trunk to B:
- merge from trunk to B
- (repeat as necessary until it's time to reintegrate into the trunk.)
We were proceeding well with option #1 (symmetrical resync), and I'm really confused why #2 and #3 seem to be the recommended approach.
Can anyone explain this?
Also, what's the right way to merge between branches B and C to exchange updates w/o re-merging to the trunk first?[I will ask separate question]
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我个人更喜欢选项 3。每当您进行合并时，Subversion 都会跟踪您要合并的修订版本以及来自何处。它在一个名为 svn:mergeinfo 的超级秘密（读作：公共知识，但不要编辑它）属性中执行此操作。 SVN 如何存储这些合并信息变得很复杂，并且根据开发人员对合并过程的熟悉程度，它可能会变得非常非常混乱。
通过将 B 合并回主干，主干会获取 svn:mergeinfo ，表明 B（在版本 X 和 Y 之间）现在位于主干上。然后，通过从主干删除并创建新的 B，B 现在拥有日志所需的所有历史记录和 svn:mergeinfo（因为 svn:mergeinfo 属性也被合并）了解分支中存在哪些修订（哪些不存在）。它还有助于避免树木冲突（没有人喜欢）。
选项 2 可能非常危险。我工作的一家公司彻底禁止仅记录合并（这成为一种可解雇的罪行），因为如果操作不当，代码可能会丢失。不过，其背后的理论是，当您将 B 重新集成到 trunk 中时，trunk 拥有 B 的所有内容（以及 svn:mergeinfo 来匹配）。对 B 进行仅记录假设 B 不会用于生产代码（因为它不会包含所有最新更新），并且仅记录合并将提供一些信息以防止树冲突（同样，没人喜欢）。
选项 1 是一个很好的中间方案。你的分支 B 会因为
svn:mergeinfo变得非常混乱，但由于它是超级秘密（读作：基本上无缝处理），除非你有大量的合并，它应该可以很好地满足你的需求。I personally prefer option 3. Whenever you do a merge, Subversion keeps track of what revisions you're merging and from where. It does this in a super secret (reads: public knowledge but don't edit it) property called
svn:mergeinfo. How SVN stores this merge information gets complicated, and depending on how familiar your developers are with the merge process, it can get very very messy.By merging B back into trunk, the trunk gets
svn:mergeinfostating that B, between revision X and Y, is now on the trunk. Then, by deleting and creating B fresh from the trunk, B now has all the necessary history andsvn:mergeinfo(since thesvn:mergeinfoproperty got merged too) for logs to know which revisions exist in the branch (and which don't). It also helps avoid tree conflicts (which nobody likes).Option 2 can be very dangerous. A company I worked for outright banned record-only merges (it became a fireable offense) because if done incorrectly, code can go missing. The theory behind it, though, is that when you re-integrate B into trunk, trunk has all of B (and
svn:mergeinfoto match). Doing a record-only into B assumes that B won't be used for production code (because it won't have all the latest updates) and the record-only merge will provide some information to prevent tree conflicts (which, again, nobody likes).Option 1 is a good in-between. Your branch B will get very cluttered with
svn:mergeinfo, but since it's super secret (reads: handled mostly seamlessly) unless you have a huge number of merges, it should serve your needs fine.您需要了解的有关重新集成合并是什么、它的作用以及为什么这样做的所有信息：
http://blogs.collab.net/subversion/2008/07/subversion-merg/
摘要：当您合并时，它都是关于分支之间“同步”的修订希望它能够正确记住您想要合并的修订版本以及您想要排除的修订版本（已合并）。这是一个问题的原因是，有时您想要包含那些必须手动解决冲突的修订 - 您不想再次执行它们；但通常您不想包含这些修订。因此，重新集成增加了管理此问题的智能，但代价是通常的灵活性 - 您无法一遍又一遍地重新集成，必须在重新集成后重新启动。
所以选项 #3 是 subversion 人员唯一推荐的选项。
Everything you need to know about what Reintegrate merge is, what it does, and why its done that way:
http://blogs.collab.net/subversion/2008/07/subversion-merg/
summary: its all about revisions that are 'synced' between branches, when you come to merge you expect it to correctly remember which revisions you want to merge, and which you want to exclude as already merged. The reason this is an issue is that sometimes you want to include those revisions where you had to manually resolve conflicts - you don't want to do them again; but generally you don't want to include those revisions. So reintegrate adds the intelligence to manage this, but at the cost of the usual flexibility - you cannot reintegrate over and over, you have to restart after reintegration.
So option #3 is the only recommended one from the subversion guys.