26

我最近遇到了一个很奇怪的颠覆行为。

我刚刚将分支的本地副本与远程分支合并。一切都很顺利，但我有 1 个树冲突（本地删除，远程更新）。

好吧，我想，适当地修改了工作副本并运行“svn resolve --accept=working -R。”。

Subversion 告诉它已经解决了我的问题并且“svn st”不再显示任何问题。所以，我尝试提交，但 svn 告诉我其中一个内部文件夹（在我的冲突文件夹内）已过时并建议 svn up，但它使文件夹再次发生冲突！

我该怎么做才能摆脱这个恶性循环？

4

5 回答 5

46 
~/sandbox/jabira > svn resolve  --accept=theirs-full testClient/
svn: warning: Tree conflicts can only be resolved to 'working' state; 'testClient' not resolved

~/sandbox/jabira  > svn resolve  --accept=working testClient/
Resolved conflicted state of 'testClient'

希望这有帮助

于 2013-05-02T19:40:53.550 回答
8

这可能有帮助，也可能没有帮助，但有时“svn cleanup”会修复奇怪的元数据问题。如果您检查干净的工作副本，干净的副本是否有同样的问题？如果是这样，那么上一个答案听起来像是朝着正确方向迈出的一步

于 2010-01-07T15:15:59.027 回答
5

您可以使用 svn resolve 命令以外的其他方式：

  1. 创建冲突文件的补丁。（或使用 svn export 备份您的冲突文件夹版本...）
  2. 更新您的存储库 (svn update)
  3. 应用之前完成的补丁（或用备份替换冲突的文件/文件夹）
  4. 提交更改 (svn commit)
于 2010-01-07T15:03:30.177 回答
4

这就是我放弃所有本地更改并使用服务器存储库中的文件的原因：

svn update --accept theirs-full

svn resolve --accept theirs-full <pathname>

出现此消息：W155027：树冲突只能解决为“工作”

不直观的下一步，但这实际上削减了 catch-22：

svn resolve  --accept=working <pathname>

现在递归地恢复所有“工作”更改。这取消了我所有的本地更改。

svn revert -R .

恢复正常，没有错误：

svn update
于 2017-11-16T23:19:45.177 回答
0

进行合并时，您可能没有更新文件夹，或者在合并之前某处存在冲突。要修复，您必须将主干（目标文件夹）恢复到以前的版本。然后对该文件夹运行清理。然后在分支文件夹（源文件夹）上运行清理。然后再次更新这两个文件夹。如果您在任何工作流程中都出现红色线条，那么您需要先恢复这些文件，然后将它们恢复到您想要的状态。然后更新文件夹（是的，再一次）。最后再次执行合并。

于 2012-04-02T19:24:02.747 回答