Subversion的奇怪问题-尝试重新创建用于我的存储库中的目录时出现“文件已存在”

所以-我以前有一个名为mysql的目录，之前有几个版本。我删除了它，并决定重新开始-但是当我尝试创建新的mysql目录时-我一直遇到“文件已存在”错误：

support:/etc/puppet/modules# mkdir mysql
support:/etc/puppet/modules# svn add mysql/
A         mysql
support:/etc/puppet/modules# svn commit -m " Test"
Adding         modules/mysql
svn: Commit failed (details follow):
svn: File already exists: filesystem '/var/lib/svn/puppet/db', transaction '11-r', path '/trunk/modules/mysql'
support:/etc/puppet/modules# svn delete mysql
svn: Use --force to override this restriction
svn: 'mysql' has local modifications
support:/etc/puppet/modules# svn --force delete mysql
D         mysql

我看到其他一些帖子建议强制更新

support:/etc/puppet/modules# svn status
support:/etc/puppet/modules# svn update
At revision 11.
support:/etc/puppet/modules# svn mkdir mysql
A         mysql
support:/etc/puppet/modules# svn commit -m "Test"
Adding         modules/mysql
svn: Commit failed (details follow):
svn: File already exists: filesystem '/var/lib/svn/puppet/db', transaction '11-s', path '/trunk/modules/mysql'

删除文件夹（和子文件夹）并从头开始创建它们时，我遇到了类似的问题。您从手动删除和重新添加文件夹时收到此错误（而文件似乎可以解决此问题）。

经过一番令人沮丧的混乱之后，发现我不得不：（
在Windows上使用TortoiseSVN）

1. 将有冲突的文件夹移出工作副本（这样我就不会丢失正在进行的工作）
2. 执行svn update将旧文件/文件夹添加回工作副本的操作
3. svn delete 夹
4. commit
5. 将新文件夹复制回工作副本（确保删除其中的所有.svn文件夹）
6. commit

不幸的是，它（A）需要两次提交，并且（B）丢失文件修订历史，因为它只能追溯到最近的重新添加（除非有人可以解释如何解决此问题）。解决这2个问题的替代解决方案是跳过步骤3和4，唯一的问题是目录中仍可能存在旧文件/不必要的文件。您可以手动删除它们。

很想听听其他人对此可能有的其他见解。

西蒙

[更新] 好的，那时候我又遇到了同样的问题，但是有问题的文件夹update不在上一次提交中，因此没有还原它。相反，我不得不浏览存储库和有问题delete的文件夹。然后add，我可以将文件夹重新放入并commit成功。

有类似的问题。要解决此问题，请从svn trunk更新，并选择本地文件优先级选项。

svn update path/ --accept=mine-full

之后您可以照常提交。当然，要小心使用它。

已经有这种类型的问题。

我的解决方案是：

从svn中删除该文件夹，但将该文件夹的副本保留在某处，然后提交更改。在备份副本中，递归删除其中的所有.svn文件夹。为此，您可以运行

#!/bin/bash

find -name '.svn' | while read directory;
do
    echo $directory;
    rm -rf "$directory";
done;

删除本地存储库，然后重新签出整个项目。不知道部分删除/签出是否足够。

问候

我设法解决了该问题，方法是恢复到我拥有mysql目录的最后一个版本，然后删除目录的内容，将新内容放入其中，然后将新信息重新输入。尽管我很好奇任何人都对那里发生的事情有更好的解释。

这是一个令人讨厌的...神秘错误，没有明确的解决方法。

更新/还原/提交在我的情况下不起作用。我没有做任何奇怪的事情-只是一些svn动作。

DID对我有用的是：

svn remove offender
svn commit
cd ..
rm -fR parent
svn up parent
cd parent
svn remove offender again
svn commit
copy offender back in (minus .svn dirs)
svn add
svn commit

至少可以说很奇怪。基本上，由于svn remove --force offender某种原因并没有完全删除。这有点像错误消息所讲的。只有移除父级，然后更新父级，这才变得显而易见，因为罪犯再次出现了！svn再次删除违规者，然后正确将其删除。

我不确定这是否对您有帮助，但是我想svn add mysql您删除它后再执行操作会重新初始化目录（因此请不要自己执行mkdir）。如果您自己创建目录，则svn希望在其中包含一个.svn目录，因为它已经“知道”该目录。

1. 重命名temp的新路径
2. 还原新路径（不是临时路径！），因此svn不会尝试提交它
3. 提交其余的更改
4. 复制存储库中的路径：svn copy -m“复制的路径” -r
5. 更新您的工作副本
6. 将所有文件从临时文件更新到更新后的新路径
7. 修订后提交本地更改
8. 祝您有美好的一天，包括历史；-)

我在Netbeans上运行的项目中遇到了这个问题。我只需右键单击该文件并更新以对其进行修复（在SVN之后）。

该解决方案可以顺利合并，并且不会丢失历史记录：

1. 将/ working-copy / offender移到临时位置。
2. 对svn + ssh：//svn.example.com/repo/offender进行svn签出到/ working-copy / offender。
3. 将文件从临时位置手动移到新的签出中。
4. 删除临时位置。

今天，当Xcode在分支合并期间崩溃时，我遇到了这个问题。该文件以某种方式被上传到svn存储库，但未正确记录在svn数据库中。我在文件本地存在的目录中运行以下命令：

svn revert bad.file
svn del svn://my.svnserver.com/svnDB/path/to/the/offending/file/bad.file

然后，我从本地系统重新添加了文件：

svn add bad.file
svn commit -m "Re adding bad.file"

成功！

如果存储库中存在由当前事务创建的对象，则会发生这种情况。

简单方案：

1. 两次检出某些目录，分别为DIR1和DIR2
2. 都进行“ svn mkdir测试”
3. 从DIR1提交
4. 尝试提交DIR2（没有svn up），SVN将返回此错误

从两个工作副本添加相同文件时，也是一样。

根据Atmocreation的解决方案，除了您无需重新签出整个项目之外，如果您有正在进行的工作，这将非常有用。

假设您有一个工作副本：

/foo/

其中包含目录：

/foo/bar/baz

并且您在提交时收到错误消息：

svn: File already exists: filesystem '/foo/bar'

将bar的内容备份到某处：

mkdir -p ~/tmp/code_backup
cp -r /foo/bar ~/tmp/code_backup

从备份中删除.svn控制目录。确保正确执行此命令，否则可能造成严重的损害！！如果不确定，请手动删除它们。

find ~/tmp/code_backup/bar -name .svn -type d -exec rm -rf {} \;

仔细检查副本是否相同：

diff -r -x .svn dist ~/tmp/code_backup/dist

从工作副本中删除有问题的目录：cd / foo rm -rf bar

然后从存储库中还原它：

cd /foo
svn update bar

从备份中复制回修改的文件：

cp -r ~/tmp/code_backup/bar /foo/

您现在应该可以提交而不会出现错误。

您需要的是svn'export'命令。这样，您可以将文件或整个目录树置于另一个分支中另一个修订版的状态。

所以像

rm file #without 'svn' in front!
svn export myrepo/path/to/file@<revision> .
svn commit

问题是，结帐发生在笔记本电脑上，在这种情况下，subversion无法应对离线同步。在其他笔记本电脑上可以再现该问题，而在台式机上，我可以很方便地签出相同的存储库。

希望这个答案对您有帮助，我花了很长时间才找到答案。