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

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

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

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

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

РЕДАКТИРОВАТЬ: последний абзац в ответе JesperE

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

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

Но я до сих пор не могу понять ошибку переключателя SVN, который теперь выглядит примерно так:

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

Любые идеи ?

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

Если вы получаете сообщение not a working copyоб ошибке, это означает, что Subversion не может найти правильный .svnкаталог там. Проверьте, есть ли .svnкаталог вcontents

Идеальным решением является новая проверка, если это возможно.

Я попал в похожую ситуацию ( svn: 'papers' is not a working copy directory) по-другому, поэтому я решил опубликовать свою историю битвы (упрощенно):

$ svn add papers
svn: Can't create directory 'papers/.svn': Permission denied

К сожалению! исправить разрешения ... тогда:

$ svn add papers
svn: warning: 'papers' is already under version control
$ svn st
~     papers
$ svn cleanup
svn: 'papers' is not a working copy directory

И даже уход papersс дороги и бег svn up(что сработало для ОП) не помогло. Вот что я сделал:

$ mv papers papers_
$ svn cleanup
$ svn revert papers
Reverted 'papers'
$ mv papers_/ papers
$ svn add papers

Это сработало.

Я решил это

1. Скопируйте резервную копию затронутых папок
2. SVN вернуть затронутые папки
3. Вставьте файлы обратно из резервной копии

В моем случае проблема была связана с удаленными .svn-файлами.

Может быть, вы просто скопировали дерево папки и пытаетесь добавить низшую.

SVN
|_
  |
  subfolder1
       |
       subfolder2   (here you get an error)

в этом случае вы должны зафиксировать каталог на верхнем уровне.

Обходной путь: Переименуйте каталог, который не является «рабочей копией». Оформите / обновите / восстановите этот каталог снова. Переместите файлы из переименованного каталога в новые изменения фиксации.

Причина: вы внесли некоторые изменения в некоторые файлы в каталоге .svn, это нарушает «рабочую копию»

Если вы создали файл в новом каталоге, вместо 'svn add newdir / newfile' используйте 'svn add newdir', потому что вам нужно добавить каталог. Все файлы внутри каталога будут добавлены по умолчанию.

Я только что получил "не рабочую копию", и для меня причиной стал Automouter на Unix. Просто свежий "cd / path / to / work / directory" сделал свое дело.

То же самое, мне нужно было обновить папку 'contrib':

1. Переместил старую папку,
2. Скопировал новый
3. Скопировал папки .svn в каждую (только три в моем случае) новую папку.

В моем случае проблема также была связана с удаленными папками .svn.

Решаемые.

Я попытался вставить папку .svn из подпапки в корневую папку. Оно работает!!!

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

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

Я также столкнулся с этой проблемой в работе svn diff, она была вызвана неправильным путем к файлу, вы должны добавить, './'чтобы указать текущий каталог файла.

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

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

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

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

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

@JesperE упоминает, что вам нужно изменить uuid. Следующее должно помочь вам достичь этого.

На SVN 1.5+ вы можете сделать svnadmin setuuid; Затем вы можете проверить правильность установки с помощью svnlook uuid. В более ранних версиях SVN это более сложный процесс. См. Http://chestofbooks.com/computers/revision-control/subversion-svn/Managing-Repository-UUIDs-Reposadmin-Maint-Uuids.html.

Кроме того, UUID «m / reponame» выглядит подозрительно. Я считаю, что это должно быть шестнадцатеричное число, похожее на число в рабочей копии, так что, возможно, это действие улучшит все вокруг :-)

[Первоначально я прокомментировал ответ @ JesperE , но создал этот ответ, чтобы сделать его более понятным для людей и более полезным для Google. С тех пор я удалил свои комментарии. ]

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

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

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

для Mac: - возьмите извлечение со стороны сервера, и откроется новое окно для выбора каталога на вашем локальном компьютере, затем поместите весь код в выбранную папку, затем откройте svn local side, добавьте и зафиксируйте проект

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

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

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

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

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

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

Это прошло, как только lockdбыло запущено на клиентском хосте nfs.

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

Я сделал новый заказ из того же проекта в другое место, затем скопировал из него папку .svn и заменил ее старой папкой .svn. После этого вызывается функция обновления svn, и все синхронизируется должным образом.

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