Ошибка SVN - не рабочая копия

Question

Недавно наш сервер SVN был изменен, и мы сделали переключатель SVN.

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

Но на самом верхнем уровне хранилища, когда я пытаюсь обновить файлы, я получаю svn: Working copy '.' заблокирован ошибка и очистка тоже не помогает. Когда я выполняю очистку, я получаю такие ошибки: svn: 'content' не является каталогом рабочей копии

Свежее оформление заказа не вариант вообще. Существуют ли другие способы очистки и снятия замков и полного переключения?

EDIT: Последний абзац в ответе Джеспера

Если вы получаете «не рабочую копию», когда делаю рекурсивный "svn cleanup" мой думаю, у вас есть каталог которая должна быть рабочей копией (т.е. каталог .svn на верхнем уровне говорит так), но ему не хватает своего каталог .svn. В этом случае вы может попытаться просто удалить / переместить каталог, а затем сделать локальное обновление

кажется решением проблемы в репозитории. Я идентифицировал эти папки и сделал новую проверку этих отдельных папок, и ничего себе, блокировки снимаются при последующей очистке! Большое спасибо JesperE !!

Но я все еще не могу понять ошибку переключателя svn, которая теперь читает что-то вроде

SVN: хранилище в 'SVN: // repourl / reponame / имя_папки' имеет uuid 'm / reponame', но туалет имеет 'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'

Есть идеи?

Answer 1

Вот что я сделал:

1. переименовать транк в trunk_
2. создать новую папку ствола
3. Повторная проверка и прерывание процесса после извлечения нескольких файлов
4. Переместить файлы из trunk_ в trunk
5. сделать svn очистку
6. Сделать SVN обновление. Это обновит статус файлов, после чего все ваши файлы будут обновлены.

Answer 2

Я только что натолкнулся на случай, когда каталог .svn находится на сервере nfs на другом компьютере, а на клиенте nfs не запущена служба блокировки файлов (lockd).

svn: E155007: '/mnt/svnworkdir' is not a working copy

Это исчезло после запуска lockd на хосте клиента nfs.

Кажется, что Subversion может выдать лучшее сообщение об ошибке, когда у него проблемы с блокировкой файлов. Это была подрывная деятельность 1.10.0

Answer 3

Недавно я использовал других разработчиков Mac У меня была такая же ситуация, проблема была; Сначала мне нужно было набрать get repo path to Terminal, но я этого не сделал, а затем сказать, каковы ваши имя пользователя и пароль.

Answer 4

Удалить папку .svn, которая присутствует на вашем локальном компьютере. Нажмите значок Windows и введите .svn, удалите всю папку. У меня это сработало.

Answer 5

Сегодня я обнаружил такую ​​же проблему /FILE_NAME/ is not a working copy утром и потратил более двух часов на ее решение. После долгих RND и Google я нашел какое-то решение, и это CHECKOUT.

1. CHECKOUT из SUBVERSION в локальный как новый проект.
2. Измените часть кода в java-файле и зафиксируйте проект.
3. Это работает для меня.

Надеюсь, это поможет вам.

Answer 6

для mac: - принять заказ со стороны сервера, и откроется новое окно для выбора каталога на локальном компьютере, затем поместить весь код в выбранную папку, затем открыть локальную сторону svn, добавить и зафиксировать проект

Answer 7

Была такая же проблема, оказалось, что у нас были Slik 1.6.2 и Tortoise на той же машине. Черепаха была обновлена ​​(и обновила рабочую копию), но Slik этого не сделал, поэтому Черепаха работала нормально, но командные строки не сработали:

svn: '.' не является каталогом рабочей копии

Удаление Tortoise и Slik, а затем переустановка Tortoise с включенными инструментами командной строки исправили это для меня.

Answer 8

Может ли это быть несоответствие формата рабочей копии? Он изменился между SVN 1.4 и 1.5, и более новые инструменты автоматически конвертируют формат, но тогда старые не будут работать с конвертированной копией.

Answer 9

svn: хранилище в 'svn: // repourl / reponame / foldername' имеет uuid 'm / reponame', но в WC есть 'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'

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

Answer 10

Вы, должно быть, удалили базовый SVN-файл из вашего проекта (который предназначен только для чтения). За счет этого вы получаете эту ошибку.

Проверьте новый проект снова, объедините изменения (если таковые имеются) вашего старого проекта SVN с новым, используя "Winmerge", и зафиксируйте изменения в вашем последнем извлечении.