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

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

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

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

Fresh checkout не является вариантом вообще. Есть ли другие способы очистки и освобождения блокировок и полностью ли переключатель ?

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

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

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

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

svn: репозиторий на 'svn: / / repourl / reponame / foldername' имеет uuid 'M / reponame', но WC есть b5b39681-0ff6-размер на 784 б-ad26-2846b9ea8e7d'

какие идеи ?

20 ответов


если вы получаете" не рабочую копию " при выполнении рекурсивного svn cleanup Я думаю, что у вас есть каталог, который должен быть рабочей копии (т. е. .svn каталог на верхнем уровне так говорит), но ему не хватает собственного


Я попал в аналогичную ситуацию (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 (который работал для OP) не исправил это. Вот что я сделал:--7-->

$ 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, это разрывает "рабочую копию"


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


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


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

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

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

решена.


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


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

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

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


СВН: репозиторий в SVN, в://repourl/reponame/имя_папки' имеет идентификатор UUID 'м/reponame, но туалет есть b5b39681-0ff6-размер на 784 б-ad26-2846b9ea8e7d'

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


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


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

Проверьте новый проект снова, объедините изменения (если таковые имеются) вашего старого проекта 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 этого не сделал, поэтому Tortoise работала нормально, но командные строки не удались:

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

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


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


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

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

надеюсь, что это будет полезно для вас.


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


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