我的工作副本指向主干。我有一个大的代码更改，我还没有准备好提交到主干，但我希望它在版本控制下，所以我决定分支（从我的工作副本创建存储库副本，而不是从 Head；并选择Switch to Branch）。在操作结束时，我得到了错误：One or more files are in a conflicted state.这看起来很奇怪；我的工作副本如何与从我的工作副本创建的全新分支发生冲突？
线索：
当我检查特定的树冲突时，我看到这样的消息：The last switch operation tried to delete/move/rename the file "xxx.cs", but the file was deleted, moved or renamed locally以及其他类似的消息。（在分支之前，我已经将一些文件移动到新文件夹中，并重命名了一些文件）。
我可以安全地将冲突标记为已解决并“保留本地文件”（在“本地添加的文件”冲突的情况下）而不必担心丢失历史记录吗？
这是一个部分答案，因为我无法真正帮助“我的工作副本如何与从我的工作副本创建的全新分支发生冲突？” 有可用的信息。我不确定到底发生了什么，但您尝试将两个逻辑变更集（一个新分支，甚至可能不是来自 HEAD；加上未提交的工作）作为一个提交，这不是一个好的开始。请参阅Subversion 最佳实践。
为了干净地创建具有未提交更改的主干分支并且不使用存储库浏览器，如果它不是最新的主干，我将首先更新我的工作副本。然后 svn 将干净且更新的主干副本复制到我的分支文件夹（我一直检出）并提交分支。如果有任何外部，我会更新 svn。或者，我会在存储库浏览器中从主干分支并检查分支。
然后我会删除（不是 svn 删除）分支中除 .svn 之外的所有内容，将当前工作集复制并粘贴到分支中，修复任何重命名和移动以保留历史记录（“修复移动”现在在 tsvn 提交对话框中可用来帮助解决这个问题），并将更改作为单独的操作提交。
回答“我能否安全地将冲突标记为已解决并“保留本地文件”（在“本地添加的文件”冲突的情况下）而不必担心丢失历史记录？那么这是一个合格的肯定，只要你所有的工作都已提交（见 svn log）你所做的就是清理工作副本。但是，为了安全起见，我会重命名此工作副本并将其放在一侧。然后我会干净地检查分支的新副本并在那里恢复我的工作。由于我们不是 100% 清楚这里发生了什么，我会强调采取安全的选择。
建议现在测试将新分支合并回主干，因为当您将其合并回来时，您将有一个痛苦的世界，这并非不可能。如果测试合并失败，您可能希望再次分支，确保使用干净且未修改的最新主干副本启动分支。