Как проверить рабочую копию Subversion

У меня есть рабочая копия Subversion с хотя бы одним отсутствующим файлом (локальная копия удалена при устранении конфликта дерева). Это смешно, потому что файл имеет версию, он появляется в репозитории, разрешение конфликтов на дереве было на 100% локально (это произошло при обновлении, и я не совершал потом), и я запускал "svn cleanup" несколько раз, но ни один из моих Клиенты Subversion (командная строка svn и TortoiseSVN) могут обнаружить, что рабочая копия повреждена. Даже не возвращая все изменения, этот файл вернулся.

Я исправлю это как обычно (свежая проверка в другом месте и копирование изменений с помощью WinMerge); На самом деле у меня другой вопрос:

Как вы можете проверить работоспособность рабочей копии?

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

=== UPDATE ===

У меня есть хорошие ответы с трюками, чтобы предотвратить повреждение рабочей копии, но мой вопрос был скорее на том, чтобы найти метод, чтобы быть на 100% уверенным, что рабочая копия является последовательной и связана с фактическим содержимым репозитория; в других работах - рабочая копия, эквивалентная команде svnadmin verify.

Пока это выглядит так:

Subversion не предоставляет такого инструмента, и возможно, что формат данных SVN даже не позволяет записать его.
Обновление для пересмотра - это метод, который, как представляется, находит (и исправляет) некоторые проблемы, хотя вам часто приходится возвращаться назад и вперед к старой ревизии, и я полагаю, что он может обнаруживать только отсутствующие файлы, если они были изменен в диапазоне ревизий.
Проверка новой рабочей копии выглядит как единственный 100% надежный метод.

Ответ 1

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

Хотя возможно, что WC-NG изменяет это для лучшего (или нет), текущий формат не является тем твердым.

Ответ 2

Это похоже на проблему, с которой я столкнулся некоторое время назад: svn - файл в рабочей копии кажется "потерянным"

цитирование wcoenen ответ verbatim:

Клиенты SVN 1.6.1 (включая TortoiseSVN) была ошибка, когда папки иногда ошибочно устанавливали глубина "пустая". Это вызывает симптомы, которые вы описываете. (Обратите внимание, что это возможно, что папка была сделана "пустой" по svn 1.6.1 и остался таким образом, хотя вы уже обновлен до нового клиента svn в среднее время.)

Чтобы исправить это, используйте "update to ревизии" в TortoiseSVN и выберите глубину "полностью рекурсивной"

Ответ 3

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

Вы также можете выполнить diff из командной строки, если хотите.

Ответ 4

У меня были подобные проблемы, когда я начал работать с SVN, используя Tortoise в Windows. Всякий раз, когда мне нужно было скопировать папку - например. при создании нового подключаемого модуля, который был основан на другом, уже существующем - я просто копировал + вставлял его в рабочую копию.

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

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

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