SVN говорит, что мне нужно выполнить очистку, но очистка не удалась

Question

!!! Это не повторяющийся вопрос, поскольку решения, предложенные в других темах, не сработали для меня.

Когда я пытаюсь зафиксировать:

Ошибка: рабочая копия 'D: \ Webs \ Drupal 6' заблокирована
Ошибка: выполните команду «Очистка».

Когда я пытаюсь выполнить очистку:

При очистке не удалось обработать следующие пути: D: \ Webs \ Drupal 6

Кто-нибудь знает, как я могу решить эту проблему?

Answer 1

Работает ли, если вы делаете

• новая «чистая» касса
• объединить файлы, которые вы изменили, в новую папку (и) извлечения с помощью инструмента слияния / различий
• 1008 * совершить *

РЕДАКТИРОВАТЬ: Обновлен пункт 2 в соответствии с комментарием Дроберта.

Answer 2

Если вы не изменили D:\Webs\Drupal 6, то проще всего было бы просто взорвать его, а затем позволить svn снова взять его с сервера.

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

Или вы можете заглянуть в каталоги .svn и попытаться почистить замки вручную.

РЕДАКТИРОВАТЬ: Вот как процедура ядерного / копирования может отменить изменения других людей:

1. Оформить заказ, получите r1;
2. Изменить foo.c, давая изменения r1 +;
3. Кто-то другой проверяет изменения в foo.c (вы, конечно, не знаете, что они это сделали, и обычный способ проверки для вас нарушен), foo.c в репо теперь r2;
4. Теперь вы уничтожаете свой репозиторий, за исключением foo.c (r1 + изменения);
5. Вы делаете заказ, получите foo.c r2.
6. Вы заменяете foo.c своей копией (r1 + изменяется). Subversion, однако, не знает об этом и думает, что ваши изменения основаны на r2, а не на r1.
7. Checkin, foo.c теперь r3, который только что потерял изменения другого человека в r2.

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

Answer 3

/ *

Я столкнулся с подобной проблемой. Предложение использовать svn cleanup было бесполезно, потому что cleanup выдает ту же ошибку (в данном случае рекурсивную). В конце концов, я понял, что импортировал рабочую область, извлеченную из удаленного хранилища, в свою локальную, поэтому заменил извлечение на экспорт, удалил путь хранилища, заново создал его и зарегистрировал. неоднозначность уровней пути на отправляющей и принимающей стороне (!), я смог оформить заказ без проблем. Это наводит меня на мысль, что, возможно, старые компоненты .svn были частью импорта и сбивали с толку Subversion, и он не знал достаточно, чтобы игнорировать их. Каждый раз, когда я пытаюсь создать хранилище, это повторный опыт.

* /

Неважно. Я сделал следующие ошибки: 1) отредактировал команду экспорта, а не команду оформления заказа; 2) пропустил полный путь от места назначения и попал в подкаталог cygwin, скрытый от Windows!

Answer 4

Я просто прошел и удалил все соответствующие папки .svn, а затем запустил очистку. работает отлично!