有时用户会使用 Windows 资源管理器复制文件并在他们应该执行 svn 存储库级别的复制或合并时提交它们。因此，SVN 没有正确跟踪这些变化。一旦我发现这一点，损坏显然已经完成，并且可能对相关文件进行了很多后续编辑。重要的是不要丢失这部分历史。当我发现这些情况发生时，我可以做些什么来追溯改进存储库中的内容？
具体来说，我有两种情况，具体取决于目标文件是否已经存在。在第一个场景中，(1) 用户执行了未记录为副本的添加。在第二种情况下，(2) 用户执行了未记录为合并的更新。
此外，源文件和目标文件都经历了也已提交的后续更新。有时，这些后续编辑也是手动对双方进行的，因此没有正确的合并信息。
可能性：可以手动将mergeinfo revprop 添加到过去的修订帮助中吗？如果是这样，我该怎么做？请考虑这两种情况。
以下是我能想到的场景以及如何解决它们（如果可能的话）：
1) 文件已被复制并已提交修改（到其原始 URL）
1a) 如果分支还没有这些文件：
1b）如果分支确实已经有这些文件：
2）文件已被复制，已进行修改但尚未提交（到其原始 URL，因为副本没有更改）
注意：由于尚未提交修改，因此没有要保存的历史记录，也与主干无关
2a) 如果分支还没有这些文件：
2b）如果分支确实已经有这些文件：
(*) 对作业使用任何常规合并工具，例如 WinMerge
更新：在您编辑后，我更了解您的情况（以上假设在手动复制后，复制文件夹的 URL 仍指向主干）
您可以尝试svn propset --revprop -r <revision> snv:mergeinfo <updated mergeinfo>在分支上使用（除非被 pre-revprop-change 钩子阻止）来“修复”合并信息，但我相信您也必须“修复”所有后续修订的合并信息，因为 svn 使用此信息其运营（例如合并）；此外，由于后者，您必须非常小心更新的内容。
我认为，一个更好的选择是只更新不正确提交到分支的修订版的日志，以包括复制文件所引用的主干的修订版。这样，如果需要，信息是可用的，但不会有扰乱 svn 未来操作的风险。这种方法的最大缺点是，将分支合并回主干可能会产生一些必须解决的冲突（因为未更新合并信息）。执行此选项的命令是svn propset --revprop -r <revision> svn:log <updated log message>
我的解决方案不是技术性的。相反，我认为你必须教你的员工他们做错了什么，并告诉他们如何做对。没什么好生气的。有时人们（包括我自己）会做一些愚蠢的事情，因为他们没有意识到有更好的方法，或者因为他们还不了解更好的方法。
如果这真的反复出现，请注意错误和成功。在板上计算结果并使其成为游戏。不挑人。一段时间后，这个问题就会消失。
假设复制的文件没有添加到新位置，我的第一个想法是执行以下操作：
$ svn move -m "Move a file" http://svn.red-bean.com/repos/foo.c http://svn.red-bean.com/repos/blah/foo.csvn up让 WC 排队