Ремонт 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: контрольная сумма, и что лучше всего исправить.

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

Answer 1

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

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

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

Answer 2

Еще один легкий способ ....

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

Answer 3

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

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

Answer 4

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

1. $ cd / var / www / myProject
2. $ svn upgrade
3. $ svn update

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

Answer 5

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

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

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

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

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

Answer 6

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

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

Answer 7

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

1) Сделать извлечение в отдельную папку

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

3) ..Profit!

Answer 8

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

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

Answer 9

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

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

Answer 10

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