Ремонт контрольной суммы SVN

Ответ 1

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

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

Если это не произойдет, я больше не буду этого делать.

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

• Повреждение диска (плохой жесткий диск или кабель IDE)
• Плохая оперативная память
• Плохая сетевая ссылка
• Какой-то фоновый процесс изменил файл за вашей спиной (вредоносное ПО)

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

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

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

• Ошибка в SVN.
• Что-то имело исключительную блокировку файла, и MD5 не могло произойти.

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

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

Ответ 4

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

svn update

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

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

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

Ответ 5

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

Ответ 6

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

Это сработало для меня, не делая ничего лишнего

Ответ 7

Я наблюдал множество решений, связанных с исправлением файла .svn/entries с новым оформлением.

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

- 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 directory with "rm -rf"
- issue "svn up" command, svn client will restore new fresh files copies

Ответ 8

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

CAVEAT: убедитесь, что ваша локальная копия является самой известной версией, и что кто-либо из вашего проекта знает, что вы делаете! (в случае, если это уже не было очевидно).

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

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

svn delete -m "удаление поврежденного файла XXXX" svn + ssh://имя пользователя @svnserver/path/to/XXXX

Удачи!

J

Ответ 9

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

Ответ 10

Если бы эта проблема, наша виртуальная машина VM все * nix наши рабочие станции win32. некоторые дураки создали файлы с тем же именем (в другом случае) в поле * nix все внезапные проверки на Win32 взрываются... потому что выигрыш не знает, какой из двух файлов с таким же именем относится к MD5, кавычки на * nix были прекрасны... оставляя нас немного почесывать головы

Я смог обновить репо в окне выигрыша, скопировав папки ".svn" из окна * nix с хорошей рабочей копией. еще не выяснили, можно ли очистить репо до такой степени, что мы сможем снова выполнить полную проверку.

Ответ 11

Еще один простой способ...

• Обновите свой проект, чтобы получить последнюю версию.
• Оформить ту же версию в другой папке
• замените папку .svn на новую копию на рабочую копию (я заменил файлы .svn-base)

Ответ 12

В качестве альтернативы проверке новой копии (которую я также должен был сделать после проверки всех других параметров), а затем слияния всех ваших изменений, которые вы ранее сохранили, поддерживалось таким же образом, но сэкономил мне значительное количество времени и, возможно, некоторые ошибки:

• Ознакомьтесь с новой рабочей копией.
• Скопируйте папку .svn из новой копии в поврежденную копию.
• Voila

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

Ответ 13

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

Ответ 14

• Отправляйте только папку с проблемным файлом из репозитория в другое место.
• Убедитесь, что .svn\text-base\<problematic file>.svn-base идентичен выданному.
• Убедитесь, что проблемный раздел файла (все строки раздела) в .svn\entries идентичен одному выданному.

Ответ 15

Вы не поверили бы этому, но я действительно исправил свою ошибку, удалив позицию <scm>...</scm> из файла-нарушителя pom.xml, который я надеялся проверить. Он содержал URL-адрес репозитория subversion, который он проверял в (это настройка Maven для!), но каким-то образом она сгенерировала ошибочную контрольную сумму для файла при проверке.

Я буквально пробовал все вышеупомянутые методы исправления этого, но безуспешно. Я столкнулся с очень редкой ситуацией, когда генератор контрольной суммы недостаточно прочен?

Ответ 16

Я также наткнулся на эту проблему и пытался найти быстрые решения, попробовал некоторое решение, данное в этом потоке. Вот как я решил эту проблему в своей среде разработки (для меня это было минимальное изменение):

1 Локально удаленный каталог, в котором файл поврежден (WEB-INF):

 svn: Checksum mismatch for 'path-to-folder\WEB-INF\web.xml':
   expected:  d60cb051162e4a6790a3ea0c9ddfb434
     actual:  16885ded2cbc1adc250e4cbbc1427546

2- Скопированный и вставленный каталог (WEB-INF) из новой проверки

3- Сделал svn up, теперь Eclipse/TortoiseSVN начал показывать конфликт в этом каталоге

4 Отмеченный конфликт как разрешенный

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

Ответ 17

В моем случае сумма была другой. Все, что я сделал, это:

1) Сделайте Отключить, чтобы разделить папку

2) Замените файл из этой папки в каталоге .svn с помощью моего файла проблемы проекта, который был указан в сообщении об ошибке svn-client

3)..Profit!

Ответ 18

1) Перейдите в папку, вызывающую проблему 2) Выполнить команду svn update --set-depth empty 3) Эта папка будет пуста и вернет пустую папку. 4) синхронизация с svn и обновление.

Эта работа для меня.

Ответ 19

Хотя это старая проблема, я думал, что буду давать 2 цента, так как я просто боролся с проблемой больше часа.

Вышеупомянутые решения либо не работали для меня, либо казались чрезмерно сложными.

Моим решением было просто удалить все svn-папки из проекта.

find . -name .svn -exec rm -rf {} \;

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

Ответ 20

У меня была эта проблема на ubuntu 14.04 и решить ее с помощью следующих шагов:

• $cd/var/www/myProject
• $svn upgrade
• $svn update

после этих шагов я могу зафиксировать файл без ошибок.

Ответ 21

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

просто

• сделать копию всех файлов проблем в той же папке.
• удалить старые с помощью svn rm
• совершить.
• затем переименуйте копии обратно в исходные имена файлов.
• снова зафиксировать.

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