Как исправить «содержащую рабочую копию область администратора отсутствует» в SVN?

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

Любая попытка обновить или зафиксировать потерпит неудачу с:

"blabla/.svn" containing working copy admin area is missing.

Я понимаю почему, но все равно есть ли это исправить.

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

Согласно этому: http://www.devcha.com/2008/03/svn-directory-svn-conisting-working.html

Извлеките папку «blabla» в другое место, а затем скопируйте ее папку .svn обратно в исходную «blabla».

у меня была похожая ситуация и я использовал svn --force delete __dir__ . Это решило проблему для меня. Затем я продолжил работать с моей рабочей копией как обычно.

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

Исправлено прямо сейчас.

Можете ли вы попробовать проверить новую копию родительского каталога?

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

svn update --set-depth infinity

заменить каталог.

Я добавил каталог в SVN, а затем случайно удалил папку .SVN внутри.

я использовал

svn delete --keep-local folderName

чтобы исправить мою проблему.

Я только что сделал 'SVN Revert / Blabla', и это сработало, папка вернулась, и я могу SVN удалить его

Ошибка «Каталог« blah / .svn », содержащий область администрирования рабочей копии», возникла, когда я попытался добавить каталог в репозиторий, но у него не было достаточных привилегий файловой системы для этого. Каталога еще не было в репозитории, но он утверждал, что находится под контролем версий после неудачного добавления.

Извлечение копии родительского каталога в другое место и замена папки .svn в родительском каталоге рабочей копии позволили мне успешно добавить и зафиксировать новый каталог (конечно, после исправления прав доступа к файлу).

Мы используем Maven и SVN. Эта ошибка была ошибочной версией целевого каталога в SVN. Удаление, которое исправило все, если этот намек кому-нибудь поможет.

Я пытался svn rm --force /path/to/dirбезрезультатно, но в итоге просто побежал, svn upи это исправило это для меня.

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

У меня была такая же проблема, когда я пытался переключить "C: \ superfolder"

Сообщения об ошибках:

Directory 'C:\superfolder\subfolder\.svn'
containing
working copy admin area is missing
Please execute the 'Cleanup' command.

После попытки выполнить «очистку» я получил следующую ошибку:

 Cleanup failed to process the following paths:
 C:\superfolder\
'C:\superfolder\subfolder\' is not a working copy directory

Решение:

1. Удалить папку «подпапка»
2. Очистить папку "Суперфолдер"
3. Попробуйте снова переключить папку "superfolder"

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

У меня была эта ошибка недавно. Это было вызвано тем, что root владел парой файлов в каталоге с этой ошибкой.

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

Из ваших постов мало что понял. Мое решение

1. Вырежьте проблемную папку и скопируйте в какое-нибудь место.
2. Получить решение из Subversion в другой рабочий каталог (только новый).
3. Добавьте вашу сохраненную папку в новую рабочую копию и добавьте ее как существующий проект (если это проект, как в моем случае).
4. Commit;

У меня была эта проблема. Просто временно переместите блаблу в другое место, попросите svn отменить ее, а затем переместите обратно. Это рассматривается как новое дополнение. Просто!

Самое простое, что мне помогло:

rm -rf _dir_in_question_
svn up

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

Я столкнулся с этой проблемой при замене сторонней библиотеки API на более новую версию, и ни одно из решений здесь не помогло мне, потому что я хотел заменить версию SVN локальной версией. Мое решение было следующим:

1) Переместите папку с ошибками в мой домашний каталог, удалите ее из SVN и подтвердите:

mv foldercausingproblem ~/
svn --force delete foldercausingproblem
svn commit --message "Temporary removing folder with old API"

2) Поместите папку обратно, добавьте ее в SVN и подтвердите снова:

mv ~/foldercausingproblem ./
svn --force add .
svn commit --message "Finally all working!"

Немного раздражает, что приходится совершать дважды, но, похоже, сработало нормально.

На всякий случай, если кто-то хочет еще одно решение:

1. Проверьте в своей новой папке как «foldername2»
2. Зайдите в Tortise SVN браузер репо
3. Переименуйте "foldername2" в "foldername"
4. В проводнике Windows сделайте обновление

Надеюсь, это кому-нибудь поможет.

-eV

Для меня такая же проблема произошла, когда я оба:

• удален (--force ) файл .map
• добавил * .map к svn:ignoreчерезsvn propedit svn:ignore .

Мое решение было:

1. отменить изменения в собственности
2. внести изменения в файлы
3. Оформить свежую копию хранилища (увы!)
4. изменить свойство и совершить

У меня была эта проблема, когда я пытался добавить каталог в SVN. Я решил это, зайдя в браузер репо. Щелкните правой кнопкой мыши в левом окне, выберите «Добавить папку» и добавьте каталог прямо в браузере репо.

Затем я удалил каталог локально (после резервного копирования, конечно), сделал очистку и обновление SVN, и все снова заработало.

Прежде всего оформите проект в вашей системе в папке. Затем удалите папку .svn из проекта конфликта и скопируйте папку .svn из новой папки извлечения и вставьте ее в папку с рабочей копией. Тогда проблема решена.

Обычная задача, с которой я столкнулся, заключалась в том, чтобы взять один каталог репозитория в стадии подготовки и скопировать его в другой репозиторий - оба в SVN и оба назывались с одинаковым именем. Способ, который работал для меня, был следующим:

svn --force delete PROBLEMATIC-DIR
svn export "https://OLD REPO-A/ new-repo-A"
svn add new-repo-A
svn commit new-repo-A