Як виправити "відсутність області адміністрування робочої копії" у SVN?

Я вручну видалив каталог, який я щойно додав у режимі офлайн у своєму сховищі. Я не можу відновити каталог.

Будь-яка спроба зробити оновлення чи здійснити помилку не вдасться:

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

Я розумію, чому, але чи все-таки це можна виправити.

Я не хочу перевіряти всю репо і додавати свої зміни до неї вручну, це займе години.

Відповідно до цього: http://www.devcha.com/2008/03/svn-directory-svn-contain-working.html

Перевірте папку "blabla" в інше місце, а потім скопіюйте її .svn папку назад у початкову "blabla".

fwiw, у мене була схожа ситуація і я використовував 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. Спробуйте знову переключити папку "суперпапка"

це працювало для мене. Будь ласка, дайте мені знати, чи це також працює для вас.

Нещодавно у мене була така помилка. Це було викликано тим, що root володіє парою файлів у каталозі, що дає цю помилку.

Після того як я змінив дозволи, все працювало так, як очікувалося.

Не дуже зрозуміли з ваших публікацій. Моє рішення таке

1. Виріжте проблемну папку та скопіюйте її в якесь місце.
2. Отримайте рішення з Subversion в інший робочий каталог (просто новий).
3. Додайте збережену папку до нової робочої копії та додайте її як існуючий проект (якщо це проект, як у моєму випадку).
4. Звернутись;

У мене було це питання. Просто тимчасово перемістіть блаблу в інше місце, скажіть 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. Перевірте у своїй новій папці як "папка2"
2. Зайдіть у браузер Tortise SVN repo
3. Перейменуйте "папку2" на "ім'я папки"
4. У Windows Explorer зробити оновлення

Сподіваюся, це комусь допоможе.

-Ев

Для мене те саме було, коли я обоє:

• видалено ( --force) .map файл
• додано * .map до svn:ignoreviasvn propedit svn:ignore .

Моїм рішенням було:

1. скасувати зміни до властивості
2. вносити зміни до файлів
3. оформити свіжу копію сховища (на жаль!)
4. змінити майно та здійснити

У мене була ця проблема, коли я намагався додати каталог у svn. Я вирішив це, зайшовши в браузер repo. Клацніть правою кнопкою миші у вікні ліворуч, вибираючи додавання папки та додавання каталогу безпосередньо у браузері репо.

Потім я видалив каталог локально (після резервної копії, звичайно), зробив очищення та оновлення 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