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

Question

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

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

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

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

=== ОБНОВЛЕНИЕ ===

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

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

• Subversion не предоставляет такого инструмента, и возможно, что формат данных SVN даже не позволяет записать его.

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

• Проверка свежей рабочей копии выглядит как единственный надежный метод на 100%.

Answer 1

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

Цитируя ответ wcoenen дословно:

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

Чтобы исправить это, используйте «обновление для редакция "пункт меню в TortoiseSVN и выберите глубину "полностью рекурсивная"

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

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