如何修复 SVN 的“工作副本文本基础文件已损坏”错误？

Question

如何修复 SVN 的“工作副本文本基础文件已损坏”错误？

34

在我愉快地提交代码到svn仓库后，突然间我们的关系变得不好了...svn发疯了，大喊：" 工作副本文本库已损坏！"

这是什么原因造成的？我该如何解决它？

Working copy text base is corrupt
svn: Commit failed (details follow):
svn: Checksum mismatch for '~/blah/.svn/text-  base/sumonet.py.svn-base'; expected: '548b9bb4b24bc580ab8694c583b28013', actual: '8b2b3cf4615de3d8520ae4841b3b0a8b'

- Niel de Wet

我已经在我的文件夹中重命名了文件，然后点击了“更新”按钮（因此，从SVN中删除了该文件），然后将其重新命名并提交该文件，就像一个新文件。 - T.Todua

在我的情况下，这种情况是由于杀毒软件的误报引起的，它悄悄地删除了我编译的“感染”的可执行文件。 - hvb

12个回答

28

这对我起作用：

svn rm --keep-local THE_CORRUPTED_FILE
svn add THE_CORRUPTED_FILE
svn ci

- geckos

4

简单而有效，应该是最佳答案。 - Hugh Jeffner

非常感谢您！ - geckos

请注意，该文件将具有特殊属性 -“替换”。它的状态不仅是“修改”，而是“替换”。 - anton_rh

这应该是迄今为止最好的答案。 - Alejandro Pablo Tkachuk

这会删除更改历史记录吗？ - Corey Alix

是的，绝对是一个很棒的答案。 - Leo Simon

16

将有问题的文件复制到其他地方，
删除并提交存储库中的文件，
将您的文件复制到SVN并提交。

- ryrysz

这对我没有起作用，我不得不替换Subversion pristine文件。（请参见我的和@siddhadev的答案） - Julian Go

1

这是唯一对我有效的解决方案。我尝试了其他的方法，但都无效。 - Michael Eakins

@MichaelEakins 我也同意，那是一个非常恶心的错误。我只使用过Surround和TFS，它们似乎比SVN更好。 - goamn

对我没有起作用。还原有问题的文件并提交是有效的。但是一旦我复制回有问题的文件并尝试再次提交，同样的错误会再次被抛出。 - tanayamitshah

@tanayamitshah 如果这是文本文件，可以尝试仅复制文件的内容（ctrl+c，ctrl+v）。 - ryrysz

强烈建议不要使用此方法来解决客户端问题。这会更改服务器上的文件，从本质上破坏历史记录。像“svn annotate”这样的功能现在将列出您作为每行的最后作者。 - chirality

16

只需进行新的检出，然后将旧工作副本中所做的更改复制到新工作副本中即可。

- khmarbaise

33

这种事情让我想要抛弃SVN，转向Mercurial或Git。 - Niel de Wet

5

先检出一个新的副本，然后用刚刚检出的文件覆盖损坏的文件（*.svn-base），也可以解决问题。 - Dmitry Chornyi

如果您有许多已更改的文件，可以从旧的工作副本/备份位置进行rsync：rsync -av --delete-during --exclude".svn" <备份位置>。 - Joe M

3

对于一个大型仓库或多个更改来说，这样做有些过度了。你只需复制受影响的文件，然后使用 svn --force delete 命令删除该文件，提交更改，再将复制品添加到仓库并提交，完成操作。具体步骤请参考其他回答。 - n13

n13，一个优美的解决方案。还有一件事要补充：你不必提交已删除的文件。cp file file2; svn rm file --force; cp file2 file; svn add file;同样有效（我使用的是MacOS Bash子版本1.8）。 - Luc Bloom

显示剩余2条评论

7

在较新的Subversion版本中，没有.svn/text-base/目录。现在.svn存储在工作根目录下的.svn/pristine中，错误信息看起来像这样:

Sending        README
Transmitting file data .svn: E155017: Commit failed (details follow):
svn: E155017: Working copy text base is corrupt
svn: E200014: Checksum mismatch for text base of '/home/user/tmp/svntest/README':
   expected:  1f9167bc01e5bc9bfcb928ff03d6700a
     actual:  e0a1692ff5cab91e3e3a0d02dabe0251

svn: E200003: Delta source ended unexpectedly

您可以使用位于https://gist.github.com/siddhadev/5814802的bash脚本来修复它。它会用新的文件替换受损的svn-base文件。

- siddhadev

3

@siddhadev 的脚本应该可以工作，但是那些更喜欢手动操作的人可以按照以下步骤进行：

将有问题的文件的最新版本导出为 lastworkingrev.txt
使用 sha1sum lastworkingrev.txt 获取其 sha1 校验和
使用 find . -name "SHA1_CHECKSUM.svn-base" 查找 subversion pristine 文件，并用 lastworkingrev.txt 的内容覆盖它
提交

- Julian Go

2

我也遇到了同样的问题，但之前的答案都没有帮助我。在我的情况下，Subversion仓库版本为1.6，但我允许IntelliJ在版本1.7上进行checkout。除了 "svn：E200014：Base checksum mismatch" 错误之外，没有任何版本不匹配的迹象。

只需使用正确版本的新树检出即可解决问题。

- Gary Rush

1

删除现有副本并重新检出，您的问题将得到解决。

- Anand Dwivedi

1

我学会了不信任将工作目录放在版本控制下。当我准备提交时，我会递归地进行差异比较，并将更改复制到检出的目录中。这样，如果 SVN 卡住了，我只需 rm -Rf 检出并进行新的检出，然后重复复制命令。

我不是来寻求解决方案的。我来找原因为什么会出现这种不稳定的行为，但没有找到任何答案。即使我是唯一使用分支并且所有操作都是通过命令行完成的，这种情况也会发生，而我相信命令行比 Eclipse 或任何其他界面更可靠。

- Jerry Miller

1

我尝试了以上所有方法，但清理不起作用。 SVN建议我检出一个新副本。但是项目太大了，而且我已经改变了太多的代码，比较会花费很多时间。以下是我保留每个更改的解决问题的方法。

1. 删除所有.svn文件夹。这个文件夹可能存在一个或多个，具体取决于SVN的版本。找到每一个单独的文件夹并删除它。 2. 检出工作文件夹。它会提示“不是空文件夹”，点击“是”。然后工作副本就恢复了。

- Linda Zeng

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- desmond13 · Accepted Answer

这是错误。

svn: E155017: Working copy text base is corrupt
svn: E200014: Checksum mismatch for text base of : '/home/.../exampleFileCorrupted.cpp'
....

清晰的解决方案，对我来说非常顺利:

注意: 将您的文件复制到SVN环境之外的另一个文件中。

cp exampleFileCorrupted.cpp ~/Desktop/

接下来请按照以下步骤操作：

进入包含受损文件的路径（该路径在“Checksum mismatch for text base of”之后指定）
使用命令 svn rm --force exampleFileCorrupted.cpp

你会看到：D exampleFileCorrupted.cpp
将第一步中保存的文件复制到当前 SVN 文件夹中，使用以下命令：

cp ~/Desktop/exampleFileCorrupted.cpp .

（别忘了最后的点号表示“复制到此处”）

使用命令 svn add 将文件添加到 SVN 中，使用以下命令：svn add exampleFileCorrupted.cpp

你会看到：A exampleFileCorrupted.cpp
提交更改，使用以下命令：svn commit -m "Commit Message"

如果这些步骤对你有帮助，请告诉我。