我最近遇到了一个非常奇怪的颠覆行为。
我刚刚将我的分支本地副本与远程分支合并。一切顺利,但我有一个树冲突(本地删除,远程更新)。
好吧,我想,我正确地修改了工作副本并运行了“svn resolve --accept = working -R。”。
Subversion告诉它解决了我的问题,“svn st”不再显示任何问题。所以,我试图提交,但是svn告诉我,其中一个内部文件夹(在我冲突的文件夹中)已经过时并建议svn up,但是它使文件夹再次发生冲突!
我该怎样做才能走出这个有意思的圈子?
答案 0 :(得分:43)
~/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'
希望这个帮助
答案 1 :(得分:8)
这可能有所帮助,也可能无效,但有时“svn cleanup”将修复奇怪的元数据问题。如果您签出一份干净的工作副本,干净的副本是否也有同样的问题?如果是这样,那么之前的答案听起来像是朝着正确方向迈出的一步
答案 2 :(得分:5)
您可以使用除svn resolve命令之外的其他方式:
答案 3 :(得分:3)
这对我来说放弃所有本地更改并使用服务器存储库中的文件是有用的:
svn update --accept theirs-full
svn resolve --accept theirs-full <pathname>
出现此消息:W155027:树冲突只能解析为“正常工作”
下一步不直观,但这实际上削减了catch-22 :
svn resolve --accept=working <pathname>
现在以递归方式恢复所有“工作”更改。这解决了我当地的所有变化。
svn revert -R .
恢复正常,没有错误:
svn update
答案 4 :(得分:0)
您在合并时可能没有更新文件夹,或者在合并之前某处发生了冲突。要修复,您必须将主干(目标文件夹)还原到以前的版本。然后在该文件夹上运行清理。然后在分支文件夹(源文件夹)上运行清理。然后再次更新两个文件夹。如果您在任何工作流程中都获得了红色线条,那么您需要先恢复这些文件,然后让它们进入您想要的状态。然后更新文件夹(是的,再次)。最后再次执行合并。