Рабочая копия XXX заблокирована, и очистка не удалась в SVN

Я получаю эту ошибку, когда я делаю svn update:

Рабочая копия XXXXXXXX заблокирован. Пожалуйста, выполните команду «Очистка»

Когда я запускаю очистку, я получаю

При очистке не удалось обработать следующие пути: XXXXXXXX

Как мне выйти из этого цикла?

Один из подходов заключается в следующем:

1. Скопируйте отредактированные элементы в другое место.
2. Удалите папку, содержащую проблемный путь.
3. Обновите содержащую папку через Subversion.
4. Скопируйте ваши файлы обратно или объедините изменения по мере необходимости.
5. совершить

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

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

Посмотрите в своей .svnпапке, там будет файл с именем lock. Удалите этот файл, и вы сможете обновить. В .svnкаталоге каждого подкаталога может быть больше файлов блокировки . Их также нужно удалить. Это можно сделать в виде пакета просто из командной строки, например, с помощью

find . -name 'lock' -exec rm -v {} \;

Обратите внимание, что вы вручную редактируете файлы в .svnпапке. Они были помещены туда по причине. Эта причина может быть ошибкой, но в противном случае вы можете повредить вашу локальную копию.

ИСТОЧНИК: http://www.svnforum.org/2017/viewtopic.php?p=6068

В моем случае я решил эту проблему, вручную удалив запись в записи блокировки файла SQLite ".svn \ wc" в таблице WC_LOCK.

Я открыл файл "WC" с редактором SQLite и выполнил

delete from WC_LOCK

После комментария eakkas вам может понадобиться удалить все записи из WORK_QUEUEтаблицы.

Самый простой способ:

1. Перейти к каталогу Parent (Папка) из проекта .
2. Pres правой кнопкой мыши
3. Нажмите на TortoiseSVN, затем нажмите Очистить ...
4. Диалог очистки появится автоматически
5. Выберите Clean up working copy status, Break locks, Fix time stamps, Vacuum pristine copies, Refresh shell overlays,Include externals
6. Pres OK

Вы успешно выполнили свою работу.

Проверьте снимки экрана для вашей справки.

Первый шаг:

Второй шаг: включите опцию «Разблокировать блокировку» (второй флажок во всплывающем окне очистки)

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

Коллега на работе постоянно видит это сообщение, и для него это происходит потому, что он удалил каталог под управлением версией SVN, не удаляя его из SVN, а затем создал новый каталог на своем месте, не под управлением версией, с тем же именем.

Если это ваша проблема ...

Есть разные способы исправить это, в зависимости от того, как / почему каталог был заменен.

В любом случае вам, вероятно, потребуется:

А) Переименуйте существующий каталог во временное имя

Б) Вернуть SVN, чтобы восстановить каталог, удаленный из файловой системы, но не из SVN

Оттуда вы бы либо

A) Скопируйте соответствующие файлы в каталог, который был удален

B) Если вы имели существенное изменение содержания в каталоге, выполните команду SVN удалить на оригинале, фиксации, и переименовать ваш новый каталог обратно до нужного имени, а затем с помощью SVN добавить , чтобы получить , что один под контролем версий.

Для меня ни одно из вышеперечисленных решений не сработало. Я нашел решение, взломав замки. Когда я выполнил svn cleanup, я выбрал «Break Locks» вместе с «Очистить статус рабочей копии».

Этот работал для меня.

1. Перейдите в корневую папку,
2. Щелкните правой кнопкой мыши и очистите
3. Проверьте все доступные варианты
4. Нажмите ок

После очистки это позволит вам обновить до последней версии.

Для меня это была вина Черепахи. Черепаха только что жаловалась, что «не может очистить, запустить очистить», но когда я запустил командную строку (svn cleanup), она ясно сказала мне, что не может удалить некоторые файлы, которые использовались, решение которых было очевидным. Как только я закрыл Visual Studio (которая держала файлы открытыми), очистка работала нормально.

Другие программы также могут держать файлы открытыми в репо, вызывая эту проблему. Excel с открытым xls был виновником в другом случае, поэтому может быть целесообразно закрыть все программы, которые могут использовать что-либо в репозитории, или даже перезагрузиться, чтобы заставить программы закрыться, а затем повторить попытку очистки.

У меня была эта проблема, потому что внешние папки не хотят быть связаны в существующую папку. Если вы добавите строку свойств svn: externals, где местом назначения является существующая (версионная или не версионная) папка, вы получите ошибку заблокированной копии SVN Woring Copy. Здесь очистка также скажет вам, что все в порядке, но обновление не будет работать.

Решение. Удалите тревожную папку из хранилища и обновите ее в корневой папке, в которой установлено свойство svn: externals. Это создаст папку, и все будет хорошо снова.

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

Самый простой способ сделать это - показать скрытые папки, а затем открыть папку .SVN. Вы должны увидеть файл нулевого КБ с именем «lock», удалив его, это решит проблему

Я столкнулся с точно такой же проблемой, используя SVN 1.7, и ни одно из упомянутых выше исправлений не сработало.

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

Потратив пару часов (не перезагружая все, так как размер моей ветки превышает 6 ГБ), я обнаружил, что в папке .svn вашей ветви есть файл db с именем "wc".

Откройте файл БД с помощью любого менеджера БД (я использовал плагин sqlite для менеджера Firefox) и перейдите к таблице WC_LOCK. Эта таблица будет содержать записи для полученных блокировок. Удалите записи из таблицы, и все готово :)

Когда у меня возникла эта проблема, я обнаружил, что запуск команды очистки непосредственно на пути к проблеме, как правило, работает. Затем я снова запускаю очистку из рабочего рута, и он будет жаловаться на какой-то другой каталог. и я просто повторяю, пока он не перестанет жаловаться.

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

Я сделал это, просто создав новую папку, проверив проект, скопировав обновленные файлы в новую папку.

Это было исправлено с новой проверкой.

Вы используете TortoiseSVN и только что обновили? У меня была такая проблема раньше при переходе с 1.4 на 1.5 и без перезагрузки. (Попробуйте перезагрузку).

Причина, по которой вам нужно перезагрузиться, заключается в том, что файл кэша становится все интереснее.

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

просто удалите папки .svn, затем запустите очистку родительского каталога. Работает отлично !!

В версиях под Mac OS: Действие -> Очистка блокировки рабочих копий при ...

Я часто получаю такую ​​проблему. Мой шаблон, который вызывает проблемы с очисткой.

1. Я открываю файл изображения в программе просмотра.
2. Я удаляю файл изображения / папку.
3. Я пытаюсь зафиксировать / обновить

Закрытие программы просмотра изображений, в которой открыт удаленный файл, решает проблему. Может быть, другое программное обеспечение может блокировать очистку таким же образом.

В основном. Я считаю, что перезагрузка компьютера может помочь в таких случаях.

SVN обычно обновляет свою внутреннюю структуру (.svn / prop-base) файлов в папке, прежде чем фактические файлы будут извлечены из хранилища. Как только файлы извлечены, это будет очищено. Часто ошибка выдается, потому что «обновление» не удалось или преждевременно отменено во время процесса обновления.

1. Убедитесь, что все файлы перечислены в каталоге .svn / prop-base
2. Удалите все файлы, которые не находятся в папке
3. уборка
4. Обновить

Теперь обновление должно работать.

Была такая же проблема, потому что я экспортировал папку в папке с контролем версий. Пришлось удалить папку из TortoiseSVN, затем удалить папку из файловой системы (TortoiseSVN не любит неверсированные подпапки ... почему бы и нет ???)

Начать поиск .... Блокировка ... Выбрать все перечисленные файлы и удалить .. Исправлено

следующее должно сделать:

Свн Статус | grep ". L" | sed 's /.* (. *) $ / \ 1 /' | awk '{длина печати ($ 1), $ 1}' | сортировать -nr | awk '{print "pushd" $ 2 "; svn cleanup; popd"}' | ш

Не удаляйте свое решение!

в папке .svn у вас есть файл с именем lock длиной 0 байт

Вы можете удалить все эти файлы из всех папок .svn в вашем решении, и это будет работать

В моем случае это сработало

Развертывание файлов на месте и новая проверка в том же месте решили эту проблему для меня.

В TortoiseSVN, чтобы выполнить инверсию на месте, перетащите правую корневую папку рабочей копии из списка файлов на себя в дереве каталогов и выберите «SVN Export versioned items here» во всплывающем меню. TortoiseSVN замечает, что место назначения совпадает с источником, и предлагает развернуть рабочую копию.

После неверсирования сделайте новую проверку в той же папке (которая теперь содержит неверсионную копию всех ваших файлов). TortoiseSVN предупредит вас, что вы просматриваете существующую папку, но вы можете продолжить.

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

Одно предупреждение: если рабочая копия содержит смешанные версии или незафиксированные изменения свойств, эта информация будет потеряна. Для меня это не обычное явление, и, учитывая выбор поврежденной рабочей копии или потерю незафиксированных изменений свойств, я предпочитаю выбрать последнее.

У меня была эта проблема, когда «очистка» работала, но «обновление» продолжало завершаться ошибкой. Решение, которое работало, состояло в том, чтобы удалить указанную папку с помощью проводника Windows, а не удаления TortoiseSVN (которое помечает удаление как нечто для фиксации в хранилище, а затем я сделал «извлечение», чтобы «обновить» папку из хранилища.

Больше информации о разнице между удалением O / S и удалением SVN здесь: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-rename.html

В частности:

Когда вы TortoiseSVN → Удалить файл, он сразу же удаляется из вашей рабочей копии, а также помечается для удаления в хранилище при следующей фиксации.

А также:

Если файл удаляется через обозреватель вместо использования контекстного меню TortoiseSVN, диалоговое окно фиксации показывает эти файлы и позволяет также удалить их из управления версиями перед фиксацией. Однако если вы обновите свою рабочую копию, Subversion обнаружит отсутствующий файл и заменит его последней версией из репозитория.

Если вы работаете в Linux, попробуйте это:

find "/the/path/to/your/directory" -name .svn -type d | xargs chmod 0777 -R

Затем выполните cleanupкоманду в этом каталоге, затем попробуйте обновить.

Я сделал следующее, чтобы исправить мою проблему:

1. Переименовываем папку с ошибками, помещая «_» перед именем папки.
2. Сделал «Очистку» родительской папки.
3. Переименовал поврежденную папку обратно в исходное имя.
4. Сделал коммит.

В обозревателе решений щелкните правой кнопкой мыши проект, в открывшемся подменю нажмите на Subversion и выберите очистку. Это решит проблему, как и для меня. Надеюсь, это сработает.

Сделать уборку

1. Удалите папку .svn.

2. Сделайте svncheckout в корневой папке.

3. Попробуйте выполнить операцию очистки.

Это решило мою проблему.