Ремонт SVN Контрольная сумма

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

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

8.08.2008 16:49:17
21 ОТВЕТ
РЕШЕНИЕ

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

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

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

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

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

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

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

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

37
8.08.2008 16:56:13
Ты прав насчет того, где произошла коррупция. Это локальная проблема .svn! Спасибо за это. Это хорошо решило мою проблему.
Matt 9.09.2011 00:06:01
В вашем примере конфликта вы можете захотеть проверить ревизию (рассматриваемого файла) до того, как коллега проверит его правки, затем применить содержимое вашего файла и, наконец, переключить измененную рабочую копию файла на ревизию HEAD этого файла. Если я не ошибаюсь, это может снова привести к правильной ситуации слияния, включая изменения в файле как ваших, так и ваших коллег.
hiergiltdiestfu 14.01.2013 15:32:43

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

svn update

воссоздать его.

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

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

5
9.08.2008 01:12:37
Я получаю сообщение об ошибке: ** Предыдущая операция не завершена; запустить «очистку», если она была прервана **
IgorGanapolsky 18.08.2016 18:25:07
эй @IgorGanapolsky лучше задай новый вопрос, если ты хочешь помочь с этим
Polsonby 11.10.2016 13:19:45

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

5
25.01.2009 08:18:24
Работал на меня! Инструкции по добавлению Eclipse / Subversion: используйте перспективу SVN Repository, чтобы проверить сломанную папку как новый временный проект (Eclipse не позволит вам перейти в обычную старую папку). Выберите «Глубина: папки в файле», чтобы избежать извлечения больше, чем нужно. Затем скопируйте <broken_folder> /. Svn из временного проекта в реальный проект, как описано в блоге Эндрю. Перезапуск Eclipse может быть необходим, и в любом случае это не повредит. (Сделайте резервную копию оригинальной <broken_folder> /. Svn на всякий случай!)
Barry Fruitman 26.01.2012 00:30:25

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

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

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

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

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

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

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

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

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

11
25.01.2009 14:04:32
В моем случае текстовые файлы были изменены глобальным поиском / заменой в моей IDE, а не фоновым процессом. Тот же принцип применяется.
Andrew Hedges 25.01.2009 21:12:29
Одним из видов «вредоносных программ», которые делали это со мной в прошлом, является антивирусный сканер.
Trejkaz 11.03.2013 02:06:53
Хорошей практикой является добавление каталогов .svn в список исключенных мест для проверки на вирусы.
myron-semack 11.03.2013 16:08:01

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

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

20
23.02.2009 21:30:14
Да, это именно то, что вызвало мою проблему, во-первых, (действительно!) Глобального поиска / замены.
Andrew Hedges 27.03.2009 00:02:44

попробуйте: svn up --force file.c

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

4
6.03.2009 18:56:18
У меня не сработало: были ошибки во время коммитов, а не во время обновлений.
Fedir RYKHTIK 6.03.2012 14:00:25

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

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

1
7.07.2009 23:14:41

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

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

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

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

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

удачи!

J

3
23.02.2018 22:08:13

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

просто

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

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

-2
6.02.2011 16:32:41

Я наблюдал множество решений от исправления файла .svn / records до новой проверки.

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

- 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
4
6.05.2011 13:58:46

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

3
30.06.2011 08:46:50
Это не работает с Eclipse / Subversion, по крайней мере, не для меня. Редактирование локальной контрольной суммы просто привело к тому, что сервер сгенерировал новую, другую контрольную сумму, и ошибка не исчезла. (Ответ Эндрю Хеджеса сработал для меня.)
Barry Fruitman 26.01.2012 00:33:22
Работал для меня идеально!
Laoneo 5.09.2013 09:39:16

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

  1. Обновите свой проект, чтобы получить последнюю версию
  2. Оформить заказ той же версии в другой папке
  3. заменить папку .svn из новой проверки на рабочую копию (я заменил файлы .svn-base)
1
18.01.2012 21:31:33
  1. Проверьте только папку с проблемным файлом из хранилища в другое место.
  2. Удостоверьтесь, что .svn\text-base\<problematic file>.svn-baseидентичен одному проверенному.
  3. Убедитесь , что проблемный раздел файла (все строки секции) в .svn\entriesидентичном один проверил.
0
24.04.2012 05:26:26

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

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

0
10.01.2013 15:19:09

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

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

0
22.04.2013 07:50:45

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

1) Сделать Check Out в отдельную папку

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

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

0
17.05.2013 09:03:33

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

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

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

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

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

0
5.09.2018 10:46:40

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

2
12.06.2014 14:02:53

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

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

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

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

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

0
14.07.2014 13:22:41

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

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

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

0
20.08.2014 05:18:00