SVN存储库中的“Phantom”目录

我以某种方式设法将SVN存储库置于不良状态。我移动了一个目录，现在我无法将其提交到新位置。SVN存储库中的“Phantom”目录

就svn status而言，目录是未知的（目录的名称是type）。

 
$ svn status 
?  type

当我尝试添加目录时，服务器说它已经存在。

 
$ svn add type 
svn: warning: 'type' is already under version control

如果我尝试更新目录，它会再次消失。

 
$ svn update type 
svn: '.' is not under version control

如果我尝试提交它，服务器会抱怨它的旧父目录不再存在。

 
$ svn commit type -m "Moving type" 
svn: Commit failed (details follow): 
svn: '/prior/trunk/src/nyu/prior/cvc3/theorem_prover/expression' path not found

为了增加神秘感，目录的内容被标记为已修改。

 
$ svn status type 
A + type 
M + type/IntegerType.java 
M + type/BooleanType.java 
M + type/Type.java 
M + type/RationalRangeType.java 
M + type/RationalType.java 
M + type/IntegerRangeType.java

如果我尝试从目录内更新，我得到这个。

 
$ cd type 
$ svn update 
svn: Two top-level reports with no target

从该目录内提交给出与上述相同的path not found错误。

怎么回事，我该如何解决？

编辑：@Rob Oxspring把我抓出来了：我在Eclipse中过于激进地移动东西。

更新：我接受@Rob Oxspring的回答“不要这样做/只是重新开始”，并采取他的建议。（a）上面的错误信息的意思是究竟和（b）如何实际上修复的问题。

来源

2008-09-05 Chris Conway

它看起来像我type是由一些Subversion感知复制命令创建，然后使用Subversion-不知道的副本移动到当前目录。根据我的经验，这种事情通常发生在将包重构操作在Eclipse中链接在一起而无需提交之间进行提交时。通常，当您复制/移动本地复制/移动的文件或文件夹时，Subversion不能很好地处理它，尽管我认为1.5版可以更好地处理它。

为了避免这种情况在未来，这些步骤之间的承诺。如果您想隐藏介入的提交，那么我建议您在分支上执行多步重构，然后将更改合并到您之后单一提交的主线中。

如果它没有太多的工作，那么我建议你又回到了一个干净的工作拷贝和重做你的变化，每一步后提交。如果你感到快乐就失去了历史，即允许新IntegerType.java不都被链接到老IntegerType.java，那么你可以采取通过BCS建议的方法：