Ремонт SVN Контрольная сумма - PullRequest
63 голосов
/ 08 августа 2008

Я использую subclipse во Flex Builder 3 и недавно получил эту ошибку при попытке зафиксировать:

svn: Checksum mismatch for '/Users/redacted/Documents/Flex Builder 3/path/to/my/file.mxml'; expected: 'f8cb275de72776657406154dd3c10348', actual: 'null'

Я работал над этим:

  1. Передача всех других измененных файлов, исключая проблемный.
  2. Копирование содержимого файла с проблемами в окно TextMate
  3. Удаление моего проекта в FlexBuilder / Eclipse
  4. Проверка моего проекта только что из SVN
  5. Копирование текста файла неисправности обратно из окна TextMate
  6. Передача изменений.

Это сработало, но я не могу не думать, что есть лучший способ. Что на самом деле происходит, чтобы вызвать ошибку svn: контрольная сумма, и что лучше всего исправить.

Может быть, важнее - это признак более серьезной проблемы?

Ответы [ 21 ]

36 голосов
/ 08 августа 2008

Файл в каталоге .svn, который отслеживает то, что вы извлекли, когда, какая ревизия и откуда, каким-то образом был поврежден для этого конкретного файла.

Это не более опасно и не критично, чем обычная проблема с нечетным файлом, и может быть вызвано различными проблемами, такими как умирание программы подрывной работы, изменение питания и т. Д.

Если этого не произойдет больше, я не смог бы извлечь из этого много.

Это можно исправить, выполнив то, что вы сделали, скопировав ваши рабочие файлы, извлеките свежую копию и добавьте измененные файлы обратно.

Обратите внимание, что это может вызвать проблемы, если у вас есть занятой проект, где вам обычно приходится объединять изменения.

Например, вы и коллега извлекаете свежую копию и начинаете работать над одним и тем же файлом. В какой-то момент ваш коллега проверяет свои модификации. Когда вы пытаетесь сделать то же самое, у вас возникает проблема с контрольной суммой. Если вы сейчас сделаете копии своих измененных файлов, выполните новую проверку, тогда Subversion потеряет отслеживание того, как ваши изменения должны быть объединены обратно.

Если в этом случае у вас не возникло проблемы, когда вы смогли проверить свои изменения, вам сначала нужно обновить рабочую копию и, возможно, урегулировать конфликт с вашим файлом.

Однако, если вы делаете новую проверку, дополненную изменениями ваших коллег, теперь похоже, что вы удалили его изменения и заменили их собственными. Нет конфликтов и нет признаков от подрывной деятельности, что что-то не так.

20 голосов
/ 24 февраля 2009

Существует также более простая причина для этого, чем просто ошибки или повреждение диска и т. Д. Я думаю, что наиболее вероятная причина этого - когда кто-то записывает рекурсивную замену текста в рабочей копии, не исключая файлы .svn.
Это означает, что первоначальные копии файлов (в основном BASE-версия файлов, которые хранятся в административной области .svn) модифицируются, и это делает недействительной сумму MD5.

@ Эндрю Хеджес: это также объясняет, почему ваше решение исправляет это.

11 голосов
/ 25 января 2009

SVN сохраняет нетронутые копии всех файлов, которые вы извлекаете, похороненных в каталогах .svn. Это называется текстовой базой. Это учитывает быстрые различия и возвраты. Во время различных операций SVN будет проверять контрольные суммы этих текстовых базовых файлов, чтобы выявить проблемы с повреждением файлов.

В общем случае несоответствие контрольной суммы SVN означает, что файл, который не должен был быть изменен, был каким-либо образом изменен. Что это значит?

  1. Повреждение диска (плохой жесткий диск или кабель IDE)
  2. Плохая RAM
  3. Плохая сетевая ссылка
  4. Какой-то фоновый процесс изменил файл за вашей спиной (вредоносная программа)

Все это плохо.

ОДНАКО Я думаю, что ваша проблема в другом. Посмотрите на сообщение об ошибке. Обратите внимание, что он ожидал некоторых хэшей MD5, но вместо этого получил значение «ноль». Если бы это была простая проблема с повреждением файла, я бы ожидал, что у вас будет два разных MD5-хеша для ожидаемого / полученного. Тот факт, что у вас есть «ноль», означает, что что-то еще не так.

У меня есть две теории:

  1. Ошибка в SVN.
  2. У чего-то была исключительная блокировка файла, и MD5 не мог произойти.

В случае № 1 попробуйте обновить до последней версии SVN. Возможно, также опубликуйте это в списке рассылки svn-devel (http://svn.haxx.se),, чтобы разработчики могли его увидеть.

В случае # 2 проверьте, не заблокирован ли файл. Вы можете скачать копию Process Explorer, чтобы проверить. Обратите внимание, что вы, вероятно, хотите увидеть, кто заблокировал файл text-base , а не тот файл, который вы пытались зафиксировать.

5 голосов
/ 09 августа 2008

Иногда я получаю похожие вещи, обычно с файлами, которых никто не видел уже несколько недель. Как правило, если вы знаете, что не работали в данном каталоге, вы можете просто удалить каталог с проблемой и запустить

svn update

чтобы воссоздать его.

Если у вас есть живые изменения в каталоге, тогда как lassevk и вы сами предложили, требуется более осторожный подход.

В общем, я бы сказал, что было бы неплохо не оставлять отредактированные файлы незафиксированными и сохранять рабочую копию аккуратной - не добавляйте в рабочую копию целую кучу дополнительных файлов, которые вы не собираетесь использовать. Регулярно делайте коммиты, а затем, если рабочая копия копируется, вы можете просто удалить все и начать все сначала, не беспокоясь о том, что вы можете потерять или не потерять, и не пытаясь понять, какие файлы сохранить. 1008 *

5 голосов
/ 25 января 2009

Только сегодня мне удалось восстановиться после этой ошибки, проверив копию поврежденного каталога в / tmp и заменив файлы в .svn / text-base на только что написанные. Я подробно описал процедуру здесь, в моем блоге . Мне было бы интересно услышать от более опытных пользователей SVN, каковы преимущества и недостатки каждого подхода.

4 голосов
/ 06 марта 2009

попробовать: svn up --force file.c

Это сработало для меня без необходимости делать что-то дополнительно

4 голосов
/ 06 мая 2011

Я наблюдал множество решений от исправления файла .svn / records до свежей проверки.

Это может быть новый способ (спасибо моему коллеге):

- go to work directory where recorder/expected checksum issue occured
- call "svn diff" and make sure that there isnt any local modifications
- cd ..
- remove trouble file's directory with "rm -rf"
- issue "svn up" command, svn client will restore new fresh files copies
3 голосов
/ 20 ноября 2009

Другой, возможно, даже более пугающий обходной путь для конфликтов контрольных сумм, который я обнаружил, выглядит следующим образом:

ПРЕДУПРЕЖДЕНИЕ: Убедитесь, что ваша локальная копия является самой известной версией, И что кто-либо в вашем проекте знает, что вы делаете! (в случае, если это уже не было очевидно).

если вы знаете, что ваша локальная копия файла «хорошая», вы можете напрямую удалить файл с сервера SVN и затем принудительно зафиксировать вашу локальную копию.

синтаксис для прямого удаления:

svn delete -m "deleting corrupted file XXXX" 
svn+ssh://username@svnserver/path/to/XXXX

удачи!

J

3 голосов
/ 30 июня 2011

Мэтт, есть более простой способ, чем вы описали - изменение контрольной суммы в файле .svn / records. Вот полное описание: http://maymay.net/blog/2008/06/17/fix-subversion-checksum-mismatch-error-by-editing-svnentries-file/

2 голосов
/ 12 июня 2014

Это произойдет, когда папка .svn повреждена. Решение: Удалите всю папку, содержащуюся в файле, и снова извлеките папку.

...