重新组织存储库后，无法将分支合并到主干中
在很长一段时间里，我们所有的开发和部署都是通过主干进行的。一段时间后，这导致生产环境与主干不同步，因为我们收到将新功能“B”移至生产的请求，但推迟了新功能“A” - 基本上我们会从主干结账到临时文件夹，然后有选择地将文件从临时文件夹合并到生产文件夹（不受版本控制）。
在与此问题斗争了太长时间之后，我最终决定重新排列存储库以允许分支，但在移动时我犯了一些错误（svn mv）主干周围，以便我可以为分支和标签文件夹腾出空间（以前没有“主干”文件夹，文件只是位于项目的父文件夹中），最终结果是我的“主干”现在比我用它创建的一些分支更新。现在我似乎无法从分支合并回主干，而不会丢失大量更改并产生大量冲突。 （我已经从主干更新了分支。）
如果我在主干上运行 svn log --stop-on-copy ，最早的修订版是 r14376，如果我在我的分支上运行它最早的修订版是r14368。 （HEAD 位于 r14710）
我怎样才能进行正确的合并而不丢失 r14368 和 r14376 之间的所有更改？我本来打算手动合并到主干，但随后我丢失了分支文件的所有修订历史记录。
For a very long time we did all of our development and deployment from trunk. After a while this led to a production environment that was out of synch with trunk as we'd get a request to move new feature "B" to production, but hold off on new feature "A" - basically we'd checkout from trunk to a temp folder then selectively merge files from temp to production (which wasn't under version control)
After wrestling with this for far too long, I finally decided to rearrange the repository to allow for branching, but I made a few mistakes while moving (svn mv) trunk around so that I could make room for the branches and tags folders (previously there was no "trunk" folder, the files just sat in the parent folder for the project) and the end result is that my "trunk" is now newer than some of the branches I created off of it. And now I can't seem to do a merge from the branches back into trunk w/o missing lots of changes and getting lots of conflicts. (I've already updated the branch from trunk.)
If I run svn log --stop-on-copy on my trunk, the earliest revision is r14376, and if I run it on my branch the earliest revision is r14368. (HEAD is at r14710)
How can I do a proper merge without losing all of my changes between r14368 and r14376? I was just going to do a manual merge to trunk, but then I lose all of my revision history for the branch files.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我尝试了几种不同的编写合并命令的方法，并认为我终于得到了我需要的东西。我基本上颠倒了合并参数的顺序，以便较新的主干首先出现，然后是较旧的分支，然后我将它们合并到主干的工作副本中：
这仅导致了少数冲突，其中大部分发生在图像文件上我刚刚接受了右侧的副本。希望这能让我未来的分支和合并能够正常工作。
I toyed around with a few different ways of writing the merge command and think I finally got what I needed. I essentially reversed the order of the merge arguments so that younger trunk came first followed by the older branch, and I then merged those into a working copy of trunk:
This resulted in only a handful of conflicts, most of which were on image files which I just accepted the right-hand copies of. And hopefully this puts me in a place where future branches and merges will work normally.
尽管如此，我还是给了你一个问题点，
我的声明是，你应该意识到你在做什么。所以公司里没有人会嘟囔说某件事不起作用，......
阅读有关 svn 中合并的书：
http://svnbook.red-bean .com/en/1.5/svn-book.html#svn.branchmerge.advanced.advancedsyntax
Nevertheless I gave you a point for question,
My statement is that you should should be aware of what you are doing. So no one in company will be mumbling that sth is not working, ....
Read on merging in svn book:
http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge.advanced.advancedsyntax
如果没有看到您的存储库发生的更多详细信息，很难回答，但也许您可以删除当前的“trunk”文件夹，然后将原始伪主干（即存储库根）复制到 HEAD 中的主干文件夹中。我认为这将为您提供原始的伪主干作为新的“主干”文件夹，历史记录完好无损。假设您首先开始修改 rX 中的存储库根目录，命令将如下所示：
然后您可以尝试将分支合并回主干。如果您与主干代码发生冲突，请尝试合并所有修订，减去您引入主干代码的修订（我假设，也许是错误的，您将主干更新作为独立提交进行）。
It's hard to answer without seeing more details of what's going on with your repo, but perhaps you could delete the current 'trunk' folder, then copy the original pseudo-trunk (i.e., the repo root) into a trunk folder in HEAD. I think this will give you the original pseudo-trunk as a new 'trunk' folder with history intact. Assuming you first started modifying the repo root in rX, the commands would be something like this:
You can then try merging your branch back into the trunk. If you have conflicts with trunk code, try merging all the revisions minus the ones where you brought in the trunk code (I'm assuming, perhaps errantly, that you do trunk updates as isolated commits).