svn: 项目<文件夹>已经过时了

Question

[赏金系统违背我的意愿自动选择的答案]

我正在使用 subclipse，并且总是在删除 Eclipse 中的文件夹并尝试提交它时，出现以下错误：

svn: Item <folder> is out of date
svn: DELETE of <folder>: 409 Conflict (http://myintranet)

通过命令行删除和提交工作正常，但出了什么问题通过 subclipse 来做吗？还有人遇到这个问题吗？

（我在 Ubuntu 9.10 和 10.04；上一个 Eclipse 版本；以及 subclipse 1.4 中遇到了这个问题 - 因为 subclipse 的下一个版本有更多错误）

--更新： 当我删除文件夹而不是文件时

Answer 1

我想如果你在那之前更新它应该有效..它确实对我有用

Answer 2

有一个简单的解决方案，无需安装一些额外的软件。我也遇到了这个“问题”，您可以执行以下操作：

1. 打开 SVN 存储库视图
2. ，转到您想要删除的文件夹并将其删除，
3. 返回到 java 视图，
4. 更新您实际删除的项目中的文件夹/ 更新您的项目也应该有效

这解决了我的问题，因为更新仅检索了我删除的文件。

Answer 3

Subclipse有很多这样的问题。 90% 的情况下它都能工作，然后就无法正常工作了！我正在使用 subclipse，因为它很好地集成到 eclipse 中，当我遇到问题或在 svn 中需要一些更大的动作（例如合并某些分支）时，我使用 Tortoisse。

我有像你这样的目录。然后我就像 @luiscolorado 建议的那样运行 TortoiseSVN，它很有帮助。 Tortoise 是一个很棒的工具（它有很多很棒的功能，可以用于比较、应用补丁、获取补丁等）。

今天，当我删除一个文件，而有人更改了同一个文件时，我遇到了问题！然后 subclipse 显示冲突（到目前为止一切正常），所以我想恢复！但是恢复按钮丢失了（在冲突模式下消失！）所以我必须进行合并，并且合并不起作用，会引发某种错误。我懒得去阅读（也许我应该阅读并将其作为错误提交给 subclipse 维护者；-(），我知道乌龟会起作用，你知道吗，它起作用了。有一个 REVERT 选项。所以

@Tom Brito，尝试命令行，尝试 Tortoisse，然后你可以查看 subclipse 更改日志并提交错误，我认为 subclipse 只是忘记向我们显示一些目录更改和更新（或者它被设计为不这样做？），但是。我可能错了。

Answer 4

Tom，

您可能想尝试 TortoiseSVN，并手动更新项目工作区。在硬盘中找到项目目录的位置，然后尝试使用 TortoiseSVN（如果您愿意，也可以使用命令行）进行更新。

导致此问题的一个常见原因是在没有“通知”SVN 的情况下删除了目录。例如，如果您使用操作系统而不是使用SVN手动删除目录，就会出现此问题。

如果您在安装 subversion 插件之前删除了该目录，但该项目已存在于存储库中，您将遇到此问题。在这种情况下，解决方案是重新创建目录、更新/提交，然后再次删除该目录。

祝你好运。

Answer 5

我的解决方案是

1. 删除文件夹中的所有项目
2. 提交到存储库将
3. 文件夹更新到 HEAD
4. 删除 Eclipse 中的文件夹
5. 提交到存储库

也许有点麻烦，但它总是有效

Answer 6

在相同情况下唯一的工作方式是通过命令行。子剪辑仍然不完美..

Answer 7

Subclipse 常见问题解答 是否解决了这个问题？

只要您在错误消息中看到“过时”，就意味着存储库中项目的修订版比本地工作副本中的副本新。
解决方案始终是运行更新，以便您的工作副本与存储库保持同步，然后再次提交（假设更新没有产生任何冲突）。

• 对于文件来说，通常很容易理解这种情况如何以及为何发生。
• 但是，Subversion 也对文件夹进行版本控制，并且通常在文件夹中最常发生此问题。
  Subversion 不允许您删除/重命名文件夹或更改其版本化属性，除非该文件夹的本地副本位于存储库中该文件夹的 HEAD 版本。

您的下一个问题可能是：
“好吧，我也许可以理解，但是为什么我的文件夹过时了？我是唯一在这个存储库中工作的人。”

这是一个有效的问题，答案在于 Subversion 的工作方式。
当您提交对文件的更改时，工作副本中的文件修订版将在提交完成后更新为新修订版，但该文件的父文件夹的版本不会更新。
这是因为该文件夹中的其他文件可能已添加/删除，并且在您运行更新之前，该文件夹并不真正处于该新版本。
这称为“混合修订工作副本”。

总而言之，答案始终是进行更新，以便将文件夹或文件更新为其 HEAD 版本。

---

关于“混合修订工作副本”：

一种特殊的灵活性是能够拥有包含文件和目录的工作副本，并混合不同的工作修订号。

Subversion 的基本规则之一是“推”动作不会导致“拉”，反之亦然。
仅仅因为您已准备好向存储库提交新更改，并不意味着您已准备好接收其他人的更改。

事实是，每次运行 svn commit 你的工作副本最终都会出现一些修订的混合。
您刚刚提交的事情被标记为比其他所有事情都有更大的工作修订。多次提交后（中间没有更新），您的工作副本将包含修订的完整组合

（这就是为什么，我相信，您无法在删除文件夹的后续提交中重现“过时”消息：您的更新确实解决“混合修订”状态。）

混合修订有局限性

您无法提交删除不完全最新的文件或目录。
如果存储库中存在该项目的较新版本，您的删除尝试将被拒绝，以防止您意外破坏尚未看到的更改。