如何更正“提交失败。文件 xxx 已过期。找不到 xxx 路径。”答案

【问题标题】：How do I correct "Commit Failed. File xxx is out of date. xxx path not found."如何更正“提交失败。文件 xxx 已过期。找不到 xxx 路径。”
【发布时间】：2010-10-23 14:57:57
【问题描述】：

我最近遇到了一个关于在 subversion 中提交合并结果的特别棘手的问题。我们的 Subversion 服务器是 @1.5.0，我的 TortoiseSVN 客户端现在是 @1.6.1。

我正在尝试将功能分支合并回我的主干。合并似乎工作正常；但是，提交失败并显示以下错误消息。

Commit failed (details follow):
File 
'flex/src/com/penbay/invision/portal/services/http/soap/ReportServices/GetAllBldgsParamsByRegionBySiteResultEvent.as' 
is out of date
'/svn/ibis/!svn/wrk/531d459d-80fa-ea46-bfb4-940d79ee6d2e/visualization/trunk/source/flex/src/com/penbay/invision/portal/services/http/soap/ReportServices/GetAllBldgsParamsByRegionBySiteResultEvent.as' 
path not found
You have to update your working copy first.

我的工作主干是最新的。我什至将一个新的文件检出到另一个文件夹中，以确保没有任何本地杂乱无章的合并。我对此进行了更多研究，我认为部分问题是用户错误。我认为我们的问题是：

我们有一些开发人员在 1.5 之前和之后提交了使用颠覆客户端的工作。我相信这有可能破坏合并信息。
在其他分支中，我们执行了部分合并。也就是说，我们并不总是在分支的根部执行合并。这是为了便于在同一分支内更新 Flex 和 .NET。
我们在分支上执行了循环（自反）合并。这样做是因为我们有多个并行分支，并且我们希望使用主干中的最新代码定期更新我们的分支。

Subversion 书籍/团队明确不推荐所有这些内容。我们已经吸取了教训，现在知道了最佳实践。但是，我们首先需要合并并提交我们最新的分支。

纠正我们遇到的问题的最佳方法是什么？

删除主干和分支中的所有合并信息是一个可行的解决方案吗？ 没有。我已经这样做了，但它不能解决我上面遇到的错误。

【问题讨论】：

标签： svn merge commit

【解决方案1】：

我刚遇到这个问题，原因似乎是一个目录被标记为冲突。修复：

svn update
svn resolved <the directory in conflict>
svn commit

【讨论】：

要在 IntelliJ 中执行此操作，您需要命令行工具支持插件。要获取它，请打开文件 > 设置（或 Ctrl+Alt+S）> 插件。单击“浏览存储库”按钮。搜索“命令行工具支持”插件。点击“安装”按钮就可以了。重新启动 IntelliJ。现在它已经设置好了，您只需单击工具 > 运行命令（或按 Ctrl+Shift+X）并在 IntelliJ 中运行您的命令。

【解决方案2】：

我在 1.6.2 服务器上得到这个，1.6.8 乌龟。全部在 Windows 上，在这个分支中没有合并。

我重命名了一个目录，并且不知何故（可能是由于 AnkhSVN）目录中的两个文件被标记为“已替换”而不是“正常”。对目录中的其他文件进行了一些额外的小改动。

还原标记为已替换的文件解决了问题。

【讨论】：

我也遇到了这个问题 - 你的解决方案为我解决了这个问题。 :)
非常简单的解决方案！只需还原文件并再次提交更改。太棒了。

【解决方案3】：

我也遇到了同样的问题，用下面的方法解决了

svn resolve --accept=working <FILE/FOLDER NAME>
svn cleanup
svn update <FILE/FOLDER NAME>
svn commit <FILE/FOLDER NAME> -m "Comment"

希望对你有帮助:)

【讨论】：

【解决方案4】：

我在尝试提交工作副本时遇到了同样的问题。我所做的是将 Subversion 报告为“找不到路径”的文件夹添加到忽略列表中。提交（应该成功）。然后将相同的文件夹添加回 Subversion。再次提交。

【讨论】：

谢谢@David，比网上的一些变通办法更容易解决

【解决方案5】：

我刚刚遇到了类似的问题，但没有任何分支或合并导致问题。我的解决方法是：

svn 将我的工作文件夹（包括未版本控制的文件）导出到临时文件夹。
将工作文件夹重命名为备份。
svn 检查后备箱。
将临时导出文件夹中的所有文件夹复制到新的工作文件夹。
svn 提交。

现在一切似乎都很好。

【讨论】：

【解决方案6】：

我今天遇到了同样的问题，而且我没有进行任何中间合并，所以从你的开篇文章中只有 #1 可能适用 - 但是我已经从 ubuntu 中的 svn 客户端和 windows 中的 tortoisesvn 进行了提交。幸运的是，在我的情况下，没有对主干进行任何更改，所以我可以用分支替换主干。那么可能不同的svn版本？这很令人担忧。

如果您使用 svn move / copy /delete 功能，但在我的情况下没有丢失历史记录 - 我 svn 移动了主干，然后 svn 将分支移动到主干。

【讨论】：

我也应该这样做，但是，考虑到这发生在时间紧迫的时候，我错误地将分支导出到主干并提交了更改，从而丢失了历史记录。幸运的是，从那以后我没有遇到过这个问题。
我认为下面@simon-d 的答案是真正的解决方案。这更像是一种解决方法:)

【解决方案7】：

我知道这是一篇旧帖子，但这个问题仍然经常发生。我发现解决它的最简单方法是重命名/删除受影响文件夹中的 .svn/all-wcprops 文件，然后运行更新并提交。

【讨论】：

【解决方案8】：

我遇到了同样的问题，不知道是什么原因，但我通过在终端输入修复了

svn update

然后我承诺并成功了！

【讨论】：

【解决方案9】：

天啊！这看起来很糟糕！我能想到的唯一选择是工作副本已损坏。

尝试删除工作副本，重新签出并再次执行合并。

如果这不起作用，则记录一个错误。

【讨论】：

看起来很糟糕。我试过执行新的结帐，但还没有运气。不幸的是，此时我唯一的办法似乎是删除我的主干中的所有文件并将分支导出到主干文件夹并重新添加所有必需的文件。

【解决方案10】：

我一直无法找到令人满意的解决方案；但是，我找到了一个不令人满意的解决方案。

我已经删除了主干中的所有文件并提交了这些更改。然后我将我的分支代码导出到主干中，添加了所有文件，并进行了大量提交。这影响了我的树干以 1:1 的比例模仿我的分支（这正是我想要的）。

不幸的是，这造成了很大的分歧，因为所有文件的历史现在都“丢失”了。但由于时间限制，似乎没有其他选择。

我仍然会对其他人可能有的任何答案感兴趣，因为我想知道根本原因是什么以及将来如何避免它。

【讨论】：

【解决方案11】：

在将具有大量更改的分支合并回我的主干后，我遇到了同样的问题。我能看到的唯一两个解决方案是执行Pacifika 提供的 svn move 解决方案或使用差异工具手动合并文件。但我确实找到了解决方法...

不工作的机器运行的是 Subversion 客户端 1.6.5。我在一台装有 Subversion 1.5.4 的机器上做了完全相同的事情，它工作了！在两台机器上，我都做了 1) 干线的干净检出，2) svn merge ...，和 3) svn commit。我的服务器是 1.5.x，值得。

希望这对某人有所帮助。

【讨论】：

【解决方案12】：

Mac 10.6.5 上的 SVN 1.6.5 有类似问题，升级到 SVN 1.6.9 并且提交成功。

【讨论】：

【解决方案13】：

当我尝试提交一个已删除的包（其中包含各种 java 类，但不再需要包中的任何内容）时，我遇到了同样的问题。

我的解决方案/解决方法以解决问题：

我还原了整个包
先删除内容
提交删除的内容
最后我再次提交了已删除的包（并且它在大多数情况下都有效:-)）

但是，有时无法提交已删除的包（其中不包含任何内容）

我的解决方法：

我在包中创建了一个虚拟类
然后我重复上述步骤

我最后的提示...

但有时它有助于简单地再次同步包/项目，然后一切都恢复正常。

关于我的配置：

日蚀霓虹灯
SVN 接口：JavaHL (JNI) 1.8.13 (r1667537)
VisualSVN 服务器管理器，版本：3.3.1

也许我可以通过我的提示帮助某人。

【讨论】：

【解决方案14】：

我想我在服务器上移动文件夹但工作副本仍绑定到旧的 SVN 文件夹结构时看到了类似的情况。在您有机会合并分支之前，不确定是否有人在您的后备箱中移动了东西。

有这种可能吗？

【讨论】：

没有人在主干中编辑过。通常禁止在主干中进行编辑，因为我们使用的是稳定的主干方法。因为我们决定像上面的答案一样从头开始，所以我担心我永远不会知道问题的真正原因。

【解决方案15】：

这看起来像是svn:mergeinfo 属性在分支和主干之间出现异常的问题。

这会导致以下问题（请原谅我的命令行指令，因为我经常使用乌龟）：

您是在主干根级别还是子文件夹级别进行合并？以我的经验，最好在根级别做，这样整个主干都认为它已经被合并到而不是只是一部分（这似乎在 1.5.0 中使 svn 非常困惑）
我的下一个问题是您是否使用了--reintergrate 参数？我永远不记得如何在乌龟中获得这个，但是当你从一个分支回到树干时，你应该使用这个参数。
您是否在重新集成之前将主干合并到分支中？这有助于消除您在合并回来时可能会看到的冲突？
您在分支上是否有任何不在根级别的svn:mergeinfo 属性？我发现这总是会导致问题。您可以随时通过svn -R pg svn:mergeinfo 找到此信息。然后，您可以记录根目录下的位置和修订，如果您发现它们相关，然后通过svn merge --record-only -r start:end <location> 将它们移动到根目录，然后使用svn pd svn:mergeinfo <location> 从子根目录中删除它们然后您需要提交这些更改
完成所有操作后，再次尝试合并。

【讨论】：

1.我们一直在进行部分合并。我们已经停止了这种做法。虽然我们仍然从主干子目录创建分支。 2. 我们很少能让 --reintegrate 选项起作用。我忘记了我们目前收到的错误。我们切换到指定要合并的修订以避免此错误。 3. 通常，我们在合并回主干之前将主干合并到分支中，以便我们可以协调分支中的合并问题。 4. svn:mergeinfo 属性似乎没有任何问题。通常情况下，我们一次只开设一家分店，但有时会开设更多分店。
我相信我们的问题源于几个问题，所有这些问题都已得到解决。 1.我们的subversion客户端不是同一个版本。有些是在不知情的情况下合并并使合并不知情的 cmets。 2. 我们正在执行部分合并（使用不同的 Subversion 客户端） 3. 我们的 Subversion 服务器是 1.5.0。上周刚刚更新到 1.6.3。与以前的版本相比，我们已经有了更好的合并体验。我认为这些都导致了我们上面的错误。

【解决方案16】：

我对此表示怀疑，但也许在您的工作目录上运行 svn cleanup 会有所帮助。

【讨论】：

【解决方案17】：

我也遇到了同样的问题，敲了敲头，发现我把represotory中的目录从“/”改成了“/trunk”，忘记做“切换”命令了，在TortoiseSVN！

【讨论】：

【解决方案18】：

哇，这个问题花了我一段时间才解决，因为我是通过 Eclipse 使用 SVN。最后，唯一对我有用的是提交所有不受影响的文件，然后（关闭 Eclipse）重命名项目目录，并从 SVN 重新签出项目。很高兴它现在可以正常工作了！

【讨论】：

【解决方案19】：

显然 SVN 不是一个非常可靠的程序。我遇到了同样的问题（将 SVN 与 Turtoise 一起使用）并通过保存 .cs 文件的内容然后返回 1 个修订版来解决它。这显示了这样的冲突： "

======= 从存储库合并的代码修订"

虽然我没有做任何特别的事情（只是一次回退了修订版）。

我用保存的内容替换了这个文件的内容，保存，然后通过 TortoiseSVN → Resolved 选择。然后我可以将修改提交到存储库。

【讨论】：

【解决方案20】：

感谢杰米·布洛克为我完成这项工作

根据杰米布洛克，

我刚遇到这个问题，原因似乎是一个目录被标记为冲突。修复：

svn更新
svn 已解决
svn 提交

【讨论】：