我在一个工作文件夹中有很多更改,在尝试进行更新时出错了。

现在当我发出'svn cleanup'时,我得到:

>svn cleanup .
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'MemPoolTests.cpp' is not under version control

MemPoolTests.cpp是另一个开发人员添加的新文件,在更新中被删除了。以前我的工作文件夹里不存在。

我能做些什么来尝试并继续前进,而不必签出存储库的新副本吗?

澄清:感谢您提出的关于将目录移出并删除一个新副本的建议。我知道这是一个选项,但这是我想避免的,因为有许多更改嵌套在几个目录深处(这应该是一个分支…)

我希望有一种更积极的方式来做清理,也许以某种方式迫使文件SVN有麻烦回到一个已知的状态(我尝试删除它的工作副本…这并没有帮助)。


当前回答

Subclipse被Windows真正邪恶的锁定行为弄糊涂了。开锁是你的朋友。这可以找到锁定的文件并强制释放锁。

其他回答

在终端中运行svn cleanup命令(如果它在Eclipse中失败,这是我的情况):

~/path/to/svn-folder/$ svn cleanup

我尝试了这里解释的不同解决方案,但没有一个奏效。

行动小组→更新头部失败:

svn: E155004:“/home/user/path/to/svn-folder”下有未完成的工作项;先运行'svn cleanup'。

Action Team→清理失败,错误相同。

解决方案:在终端上执行svn cleanup命令。

命令执行成功。

然后Team→Update in Eclipse再次工作。

注意:我的SVN版本是1.9.3。

如果svn cleanup不起作用,还检查Chris的回答。

我遇到一个问题,在更新之后,SVN显示一个文件夹是冲突的。奇怪的是,这只能通过命令行看到- TortoiseSVN认为这一切都很好。

#>svn st
!       my_dir
!       my_dir\sub_dir

SVN清除,SVN恢复,SVN更新和SVN解决都无法解决这个问题。

我最终解决的问题如下:

在.svn目录中查找“sub_dir” 使用RC ->属性取消选中条目文件上的“只读”标志 打开条目文件,删除行“unfinished…”和相应的校验和 保存,并重新启用只读标志 对my_dir目录重复此操作

在那之后,一切都很好。

注意,我没有任何局部变化,所以我不知道如果你有风险。我没有使用其他人建议的删除/更新方法——我是在my_dir/sub_dir/sub_sub_dir目录上尝试该方法(开始时具有相同的症状)才陷入这种状态的——所以我不想冒险让事情再次变得更糟!

不是很切题,但如果有人像我一样看到这篇文章,可能会有帮助。

这个答案只适用于1.7之前的版本(感谢@ŁukaszBachman)。

Subversion将它的信息存储在每个文件夹中(在.svn中),所以如果你只是处理一个子文件夹,你不需要签出整个存储库-只需要签出已经中断的文件夹:

cd dir_above_borked
mv borked_dir borked_dir.bak
svn update borked_dir

这将为您提供borked文件夹的良好工作副本,但您仍然在borked_dir.bak中备份了更改。同样的原则也适用于Windows/TortoiseSVN。

如果在独立文件夹中有更改,请查看

svn checkout -N borked_dir   # Non-recursive, but deprecated

or

svn checkout --depth=files borked_dir
# 'depth' is new territory to me, but do 'svn help checkout'

我将同事的.svn目录复制到我的目录中,然后更新我的工作副本,从而解决了这个问题。这是一个很好的、快速的、干净的解决方案。

在SVN 1.7中,情况发生了变化,删除. SVN目录中的日志文件的流行解决方案在迁移到数据库工作复制实现后不再可行。

以下是我做的似乎有效的方法:

删除工作副本的.svn目录。 在一个新的临时目录中启动一个新的签出。 取消签出(我们不想等待所有东西都被拉下)。 对取消的签出运行清理。 现在我们有了一个新的.svn目录和一个干净的数据库(虽然没有/很少的文件) 将这个.svn复制到旧的、损坏的工作目录中。 运行svn update,它将使新的部分.svn目录与旧的工作目录保持一致。

这一切都有点令人困惑,就流程而言。本质上,我们所做的是删除损坏的.svn,然后为相同的签出路径创建一个新的.svn。然后,我们将这个新的.svn移到旧的工作目录中,并将其更新到repo。

我刚刚在TSVN中这样做了,它似乎工作得很好,不需要完整的签出和下载。

杨晨