Subversion的奇怪问题 – 当试图重新创build一个用于我的仓库的目录时，“File already exists”
所以 – 我以前有一个名为mysql的目录。 我删除它，并决定重新开始 – 但是当我尝试创build新的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 我看到其他一些postbuild议强制更新
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'
当我删除一个文件夹 （和子文件夹），并从头开始重新创build它们时，我遇到了这样的问题。 你从手动删除和重新添加文件夹 （而文件似乎应付这个问题）得到这个错误。
经过一番令人沮丧的混乱，发现我不得不：
（在Windows上使用TortoiseSVN）
- 将冲突的文件夹移出工作副本（这样我就不会失去正在进行的工作）
- 做一个
svn update，将旧的文件/文件夹添加回工作副本 -
svn delete文件夹 -
commit - 将新文件夹复制回工作副本（确保删除里面的所有.svn文件夹）
-
commit
不幸的是它（A）需要两个提交，（B）丢失文件修订历史，因为它只追踪到最近的重新添加（除非有人可以解释如何解决这个问题）。 解决这两个问题的另一种解决scheme是跳过步骤3和步骤4 ，唯一的问题是旧的/不必要的文件可能仍然存在于您的目录中。 你可以手动删除这些。
希望听到其他人可能有更多的见解。
西蒙。
[更新]好的，我刚才又遇到了同样的问题，但是这个文件夹并不在最后一次提交，所以update没有恢复。 相反，我不得不浏览存储库并delete的文件夹 。 然后我可以add文件夹并成功commit 。
有类似的问题。 为了解决这个问题，从svn trunk更新本地文件的优先级选项。
svn update path/ --accept=mine-full
之后你可以照常提交。 当然，要小心使用它。
已经有这种types的问题。
我的解决scheme是：
从svn删除该文件夹，但保留该文件夹的副本，提交更改。 在备份副本中，recursion删除其中的所有.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
奇怪的是，至less可以说。 基本上， svn remove --force offender并没有因为某种原因彻底删除。 这是什么错误消息说的。 只有删除父母，然后更新父母，这是否变得明显，因为然后罪犯再次出现！ svn再次删除罪犯，然后妥善删除它。
我不确定这是否对你有所帮助，但是我想当你删除它之后，当你svn add mysql一个svn add mysql时候，它会重新实例化目录（所以不要自己去做一个mkdir）。 如果你自己创build一个目录，svn需要一个.svn目录，因为它已经“知道”了。
- 将新path重命名为temp
- 恢复新的path（不是临时！），所以svn不会尝试提交它
- 执行其余的更改
- 复制存储库中的path：svn copy -m“copied path”-r
- 更新你的工作副本
- 将所有文件从临时文件更新到新的path，这是来自更新
- 提交自修改以来的本地更改
- 有一个愉快的一天，包括历史;-)
我在Netbeans上运行的项目中遇到了这个问题。 我只需右键单击该文件并更新以修复它（在SVN之后）。
这个解决scheme合并顺利，不会失去历史：
- 移动/工作复制/罪犯到一个临时的位置。
- 做svn + ssh：//svn.example.com/repo/offender svn结帐到/ working-copy / offender。
- 将文件从临时位置手动移动到新的结帐中。
- 删除临时位置。
如果存储库中存在对象，则通过当前事务创build这种情况。
简单的情况：
- 检出一些目录两次，如DIR1和DIR2
- 在'svn mkdirtesting'中
- 从DIR1提交
- 尝试提交DIR2（没有SVN），SVN应该返回这个错误
从两个工作副本添加相同的文件时也是如此。
根据Atmocreation的解决scheme，除非您不需要重新签出整个项目，如果您现有的工作正在进行中，这是非常有用的。
假设你有一个工作副本：
/foo/
其中包含目录：
/foo/bar/baz
并且在提交时收到错误消息：
svn: File already exists: filesystem '/foo/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/
您现在应该可以提交没有错误。
当Xcode在分支合并期间崩溃时，我今天遇到了这个问题。 不知怎的，file upload到svn库，但没有正确logging在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"
成功！
你需要的是svn'export'命令。 有了这个，你可以把一个文件或整个目录树在另一个分支的另一个版本的状态。
所以像
rm file #without 'svn' in front! svn export myrepo/path/to/file@<revision> . svn commit
问题是，结帐发生在笔记本电脑上，在这种情况下，颠覆不能应付脱机同步。 问题是在其他笔记本电脑上重现，而在桌面上我没有问题检出同一个存储库。
我希望这个答案能帮助你，我花了很长时间才发现。
