SVN говорит, что мне нужно выполнить очистку, но очистка не выполняется
!!! Это не повторяющийся вопрос, поскольку решения, предложенные в других темах, у меня не работали.
Когда я пытаюсь совершить:
Ошибка: рабочая копия 'D: \ Webs \ Drupal 6' заблокирована
Ошибка: выполните команду «Очистить».
Когда я пытаюсь выполнить очистку:
При очистке не удалось обработать следующие пути: D: \ Webs \ Drupal 6
Кто-нибудь знает, как я могу решить эту проблему?
Ответы 4
Это сработает, если вы это сделаете
- новая "чистая" касса
- объединить файлы, которые вы изменили, в новую папку (и) оформления заказа с помощью инструмента слияния / сравнения
- совершить
?
Обновлено: обновлен пункт 2 в соответствии с комментарием Дероберта.
@derobert: как ?! Если вы выполните проверку, вы получите все, что есть в репозитории (вы потеряете только свои изменения, но 2-й пункт divo решает это). Изменения других людей будут в их локальных рабочих копиях. +1, у меня это уже много раз срабатывало.
@derobert: Я также не вижу здесь никакого риска, кроме потери собственных изменений, если вы не будете осторожны с шагом 2. Также использовал этот метод несколько раз, прежде чем успешно.
@Ricardo, @divo: Я обновил свой ответ, чтобы объяснить, как это может произойти.
Если вы не модифицировали D:\Webs\Drupal 6, то проще всего было бы просто уничтожить его, а затем позволить svn co снова захватить его с сервера.
Или, если вы изменили файлы, вы можете попробовать предложение divo, но будьте осторожны, чтобы случайно не отменить изменения, сделанные другими людьми.
Или вы можете заглянуть в каталоги .svn и попытаться очистить блокировки вручную.
Обновлено: Вот как процедура Nuke / Copy может отменить изменения, сделанные другими людьми:
- Оформить заказ, получить r1;
- Измените foo.c, дав изменения r1 +;
- Кто-то другой проверяет изменения в foo.c (вы, конечно, не знаете, что они сделали это, и нормальный способ проверки для вас не работает), foo.c в репозитории теперь r2;
- Теперь вы уничтожите свой репозиторий, кроме foo.c (r1 + changes);
- Вы делаете кассу, получаете foo.c r2.
- Вы заменяете foo.c своей копией (r1 + изменяется). Subversion, однако, не знает об этом и думает, что вы основываете свои изменения на r2, а не на r1.
- Checkin, foo.c теперь r3, который только что потерял изменения другого человека в r2.
Надеюсь, это проясняет, как эта процедура может случайно отменить изменения, сделанные другими людьми. Этого можно избежать, но только если вы знаете, как это может случиться!
Я просто просмотрел и удалил все соответствующие папки .svn, а затем запустил очистку. работает отлично!
удаление папок .svn отключило мою папку от svn!
/ *
Я столкнулся с похожей проблемой. Предложение использовать svn cleanup было бесполезно, потому что очистка дала ту же ошибку (в данном случае рекурсивную). В конце концов я понял, что импортировал рабочую область, извлеченную из удаленного репо, в свое локальное, поэтому я заменил оформление на экспорт, удалил путь репо, воссоздал его и зарегистрировал. После одной неудачной проверки, вызванной неоднозначность уровней пути как на отправляющей, так и на принимающей стороне (!), я смог проверить без проблем. Это наводит на мысль, что, возможно, старые компоненты .svn были частью импорта и сбивали с толку подрывную деятельность, и он не знал достаточно, чтобы их игнорировать. Каждый раз, когда я пытаюсь создать репозиторий, я получаю новое обучение.
* /
Неважно. Я сделал следующие ошибки: 1) редактировал команду экспорта, а не кассовую; 2) пропустил полный путь от места назначения и оказался в подкаталоге cygwin, скрытом от Windows!
Остерегайтесь, если вы это сделаете, вы можете случайно отменить изменения, внесенные другими пользователями.