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

Question

Я использую 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: checksum, и что лучше всего исправить?

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

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

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

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

Answer 4

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

svn update

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

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

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

Answer 5

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

Answer 6

попробуй:svn up --принудительный файл.c

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

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

Answer 8

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

Answer 9

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

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

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

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

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

удачи вам!

J

Answer 10

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

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

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

Answer 11

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

Answer 12

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

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

Answer 13

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

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

Answer 14

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

Answer 15

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

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

Answer 16

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

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

Answer 17

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

1) Перенесите проверку в отдельную папку

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

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

Answer 18

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

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

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

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

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

Answer 19

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

1. $ cd /var/www/MyProject
2. обновление $ svn
3. обновление $ svn

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

Answer 20

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

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

Answer 21

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

просто

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

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