Восстановить контрольную сумму SVN

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

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

Если этого не случится, я бы ничего из этого не извлек.

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

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

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

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

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

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

svn update

воссоздать это.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

пытаться: svn up --force file.c

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

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

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

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

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

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

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

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

удачи!

J

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

просто

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

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

Я наблюдал множество решений, от исправления файла .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's directory with "rm -rf"
- issue "svn up" command, svn client will restore new fresh files copies

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1) Сделайте выписку в отдельную папку

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

3) ..Прибыль!

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

1. Проверить свежую рабочую копию
2. Скопируйте папку .svn из вашей новой копии в вашу поврежденную копию
3. Вуаля

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

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

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

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

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

Приведенные выше решения либо не работали для меня, либо казались слишком сложными.

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

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

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

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

1. $ cd / var / www / myProject
2. $ svn upgrade
3. $ svn обновить

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