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

184

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

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

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

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

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

е-удовлетворяться
источник

Ответы:

148

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

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

отметка
источник
62
У меня так много SVN. Сортировка .svnподкаталогов повсюду, должно быть, была худшей идеей в истории контроля версий.
Йоханнес Фаренкруг
9
Ребята, ознакомьтесь с приведенными ниже предложениями Роба, это гораздо проще, чем текущее решение.
Мухаммед Ариф
Мохаммед, спасибо за внимание. Это сработало для меня. Пытался заставить SVN игнорировать каталог журналов, и удаление .svn привело меня к этой проблеме. Решение Роба это решило.
Асмор
Йоханнес, я не сторонник SVN, но преимущество каталогов .svn в том, что вы можете проверять подкаталоги репозитория и поддерживать контроль версий.
Джозеф Перси
@MohammadArif, теперь есть два «Роба»
Чарльз Клейтон,
123

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

Мэтт Сеттер
источник
2
Это сработало и для меня. Не удалось выполнить обновление и очистку, поскольку каталог никогда не находился в хранилище, но рабочая копия была уверена, что он находится под контролем редакции. Интересно, добавил ли я каталог, но затем удалил его, прежде чем зафиксировать?
Магнус
1
Это очень хорошо. Я добавил каталог, удалил .svn, но никогда не фиксировал. На этот раз все получилось
Эрик
8
Спасибо; этот ответ сэкономил мне много времени. svn cleanupтогда svn --force delete <directory-that-doesn't-exist-but-should>работал на меня.
mpontillo
Работая со второй попытки, я сначала попробовал без --force, который каким-то образом оставил файл блокировки в .svn родительского файла, который мне пришлось удалить вручную. Второй раз с --force исправил проблему.
Йорн Хорстманн
3
Хм, эта команда просто выдает мне ту же ошибку «рабочей копии».
Оскар
72

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

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

Maurizio
источник
3
Я не могу поверить ... Я попробовал все ... и это было так просто! Это отлично сработало, большое спасибо !!!!!
Lucaferrario
Это самый прямой ответ.
Joaerl
35

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

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

svn update --set-depth infinity

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

Роб Уэллс
источник
Я попробовал это, но по какой-то странной причине, я получаю пустой каталог. Я не понимаю ...
Э-Сат
Явное <code> svn update blabla </ code> от родителя также должно работать.
jmanning2k
@ jmanning2k, я тоже так думал, но ОП сказал, что попробовал, и это не сработало.
Роб Уэллс
Чтобы уточнить, я предложил --set-depth infinityиз-за этого: stackoverflow.com/questions/866835/…
Вим Коенен
1
Для этого нужно гораздо больше откликов ... быстрое и относительно (для стандартов SVN) чистое решение.
Дино
6

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

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

svn delete --keep-local folderName

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

Александр
источник
Это сработало для меня, когда моя среда IDE добавила каталог, а затем я переместил каталог с тем же именем на место до его фиксации.
неприветливым
попробовал это, но все еще не мог совершить. Я использовал, svn checkout --force [url]который воссоздал папку .svn
Lex
4

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

скуловая кость
источник
Спасибо. У меня была эта проблема, и я попробовал ваше предложение, и оно сработало.
Борич
3

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

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

Роб ДиЧуччо
источник
2

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

Маду
источник
Удаление что / откуда точно?
DerMike
maven создает "целевой" каталог при сборке. Обычно никто не должен проверять это. При повторной проверке при следующей проверке возникла проблема с разрешением. Удаление «целевой» директории из SVN решило проблему.
Маду
2

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

Натан Дж. Б.
источник
1

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

Casebash
источник
1

У меня была такая же проблема, когда я пытался переключить "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"

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

Andreas
источник
1

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

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

JJ
источник
1

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

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

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

борный
источник
1

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

rm -rf _dir_in_question_
svn up

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

allprog
источник
1

Я столкнулся с этой проблемой при замене сторонней библиотеки 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!"

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

Джейми Браун
источник
Как правило, мне нравится работать над кодом отдельно от моей рабочей копии репозитория (IDE, компиляторы, анализаторы ошибок и т. Д. Не любят .svn, и в Eclipse afaik нет команды «EVERYONE IGNORE .SVNs EXCEPT SVN!»); это означает, что основной процесс фиксации SVN для меня: 1. извлечение рабочей копии репо 2. удаление корневого каталога проекта У меня есть обновление для 3. копирование и вставка обновленного каталога проекта в родительский каталог проекта в рабочей копии 4. svn добавить --force <имя_проекта> 5. зафиксировать. Обычно это работает, но иногда может выдавать ошибку OP. Исправление Джейми Брауна сработало в моем случае
CCJ
0

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

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

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

-eV

Ev.
источник
решение только для Windows.
Raptor
0

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

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

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

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

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

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

пятнышко
источник
Я мог бы добавить, что это добавлено в мой файл "svn sucks".
Спек
0

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

Джайдип Сингх Райквар
источник
0

Обычная задача, с которой я столкнулся, заключалась в том, чтобы взять один каталог репозитория в стадии подготовки и скопировать его в другой репозиторий - оба в 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
texasdave
источник