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

Я использую подклип в 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)

Решение

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

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

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

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

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

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

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

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

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

svn update

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

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

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

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

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

Я наблюдал множество решений, от исправления файла .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

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

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 из вашей новой копии в вашу поврежденную копию
  3. Вуаля

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Только сегодня мне удалось избавиться от этой ошибки, проверив копию поврежденного каталога в / 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://[email protected]/path/to/XXXX

удачи!

J

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

просто

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

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

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