Bzr 推送错误：合并到主线后出现分歧的存储库
我最近开始使用一个 Bzr 共享存储库来管理我的项目。我通过从一个独立的存储库分支得出这一点，到目前为止我一直在向该存储库进行增量提交。这个新的共享存储库有一个“/ trunk，/branches”布局：
--xxxx_shared
--trunk
--src
--lib
--doc
--branches
所以我将此存储库的主干中的一些更改合并到主线中，但是当我后来尝试从主干中推送一些进一步的更改时，我收到一条错误，指出两个分支已经分道扬镳了。我已将合并提交到主线中，因此出现了分歧。但是，鉴于必须提交任何合并，如何避免这种情况呢？或者我严重误解了事情？
为了解决这个冲突，我从主线 BACK 合并到共享主干分支中。我怀疑这是一个错误，因为我现在有 /xxxx_shared/trunk 的修订历史记录，如下所示：
------------------------------------------------------------
revno: 74 [merge]
committer: Chris <[email protected]>
branch nick: trunk
timestamp: Wed 2011-12-14 03:47:49 +0000
message:
Committing merge from parent branch.
------------------------------------------------------------
revno: 71.1.1 [merge]
committer: Chris <[email protected]>
branch nick: mainline
timestamp: Tue 2011-12-13 21:13:06 +0000
message:
Merged WinAPI toolbar updates from /projects/xxxx_shared/trunk.
------------------------------------------------------------
revno: 73
committer: Chris <[email protected]>
branch nick: trunk
timestamp: Wed 2011-12-14 03:33:35 +0000
message:
Updated the WinAPI toolbar button code...
因此上面的 71.1.1 已从主线合并，并引用来自 /projects/xxxx_shared/trunk 的合并（共享仓库）到主线。
我希望这一切都清楚。但如何解决这个问题，恢复线性发展呢？为了避免将来发生此类事情，Bzr 保守的“最佳实践”是什么？我仍然拥有原始独立存储库的未修改副本，因此如果需要，我可以随时返回并重新开始。
I have very recently started using a Bzr shared repository to manage my project. I derived this by branching from a standalone repository to which I had been up to now making incremental commits. This new shared repository has a '/trunk, /branches' layout:
--xxxx_shared
--trunk
--src
--lib
--doc
--branches
So I merged some changes from the trunk of this repository into the main line, but when I later attempted to push some further changes from the trunk I got an error stating that the two branches had diverged. I had committed the merge into the main line, and so there was a divergence. But how does one avoid this, given that one has to commit any merge? Or am I seriously misunderstanding things?
In order to resolve this conflict I merged from the main line BACK into the shared trunk branch. I suspect this was a mistake, since I now have a revision history for /xxxx_shared/trunk which looks like this:
------------------------------------------------------------
revno: 74 [merge]
committer: Chris <[email protected]>
branch nick: trunk
timestamp: Wed 2011-12-14 03:47:49 +0000
message:
Committing merge from parent branch.
------------------------------------------------------------
revno: 71.1.1 [merge]
committer: Chris <[email protected]>
branch nick: mainline
timestamp: Tue 2011-12-13 21:13:06 +0000
message:
Merged WinAPI toolbar updates from /projects/xxxx_shared/trunk.
------------------------------------------------------------
revno: 73
committer: Chris <[email protected]>
branch nick: trunk
timestamp: Wed 2011-12-14 03:33:35 +0000
message:
Updated the WinAPI toolbar button code...
So 71.1.1 above has been merged from the main line, and refers to the merge FROM /projects/xxxx_shared/trunk (shared repo) TO the main line.
I hope all this is clear. But how can I resolve this issue so as to recover a linear line of development? And what would be a conservative 'best practice' with Bzr so as to avoid this kind of thing in the future? I still have an unmodified copy of the original standalone repository, so I can always go back to that and start over again, if need be.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果你想让“主线”作为“主干”的精确镜像，你应该只从主干推到主线，或者最好从主干拉到主线：
如果你有分歧的分支情况，那么你需要使用命令
bzrmissing来了解为什么会出现分歧，然后合并到 trunk，并执行上面的pull命令。因此，您的主线将是主干线的精确副本。If you want to have "main line" as exact mirror of the "trunk" you should only push from trunk to main line, or better pull from trunk into main line:
If you have diverged branches situation then you need to use command
bzr missingto understand why there is divergence occurs, after that merge to trunk, and execute thepullcommand above. Thus your main line will be exact copy of trunk.