Ответ 1
При запуске все сначала не вариант...
Я удалил файл журнала в каталоге .svn
(я также удалил .svn/props-base
файл в .svn/props-base
), сделал очистку и возобновил свое обновление.
У меня много изменений в рабочей папке, и что-то напортачило, пытаясь сделать обновление.
Теперь, когда я запускаю 'svn cleanup', я получаю:
>svn cleanup .
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'MemPoolTests.cpp' is not under version control
MemPoolTests.cpp - это новый файл, добавленный другим разработчиком, который был сброшен при обновлении. Он не существовал в моей рабочей папке раньше.
Могу ли я что-нибудь сделать, чтобы попытаться продвинуться вперед без необходимости извлекать свежую копию хранилища?
Пояснение: Спасибо за предложения о том, как убрать каталог с пути и убрать новую копию. Я знаю, что это вариант, но я бы хотел его избежать, так как есть много изменений, вложенных в несколько каталогов (это должна была быть ветвь...)
Я надеюсь на более агрессивный способ очистки, возможно, каким-то образом заставить файл SVN испытать проблемы с возвращением в известное состояние (и я попытался удалить его рабочую копию... это не помогло).
При запуске все сначала не вариант...
Я удалил файл журнала в каталоге .svn
(я также удалил .svn/props-base
файл в .svn/props-base
), сделал очистку и возобновил свое обновление.
Все изменилось с помощью SVN 1.7, и популярное решение об удалении файла журнала в каталоге .svn нецелесообразно при переходе к реализации рабочей копии базы данных.
Вот что я сделал, что, казалось, сработало:
Это все немного запутанно, мудрый процесс. По существу, мы делаем удаление поврежденного .svn, а затем создаем новый .svn для одного и того же пути проверки. Затем мы переносим этот новый .svn в наш старый рабочий каталог и обновляем его до репо.
Я только что сделал это в TSVN и, похоже, работает нормально и не требует полной проверки и загрузки.
-Jody
Взгляни на
Сводка исправления сверху ссылка (спасибо Anuj Varma)
Установите оболочку командной строки sqlite (sqlite-tools-win32) с http://www.sqlite.org/download.html
sqlite3.svn/wc.db "select * from work_queue"
SELECT должен показать вам вашу папку/файл, который вас обидел, как часть рабочей очереди. Что вам нужно сделать, это удалить этот элемент из рабочей очереди.
sqlite3.svn/wc.db "delete from work_queue"
Это оно. Теперь вы можете запустить очистку снова - и это должно работать. Или вы можете перейти непосредственно к задаче, которую вы выполняли, прежде чем будет предложено запустить очистку (добавление нового файла и т.д.)
Если все остальное терпит неудачу:
Последний вариант (я использую 1.9.5) решает эту проблему, добавив опцию "Блокировки прерываний" в меню очистки. Просто убедитесь, что этот флажок установлен при очистке.
Этот ответ относится только к версиям до 1.7 (спасибо @ŁukaszBachman).
Subversion хранит информацию о каждой папке (в .svn), поэтому, если вы имеете дело с подпапкой, вам не нужно извлекать весь репозиторий - только та папка, которая разбилась:
cd dir_above_borked
mv borked_dir borked_dir.bak
svn update borked_dir
Это даст вам хорошую рабочую копию папки borked, но ваши изменения сохранятся в файле borked_dir.bak. Тот же принцип применим к Windows/TortoiseSVN.
Если у вас есть изменения в изолированной папке, посмотрите на
svn checkout -N borked_dir # Non-recursive, but deprecated
или же
svn checkout --depth=files borked_dir
# 'depth' is new territory to me, but do 'svn help checkout'
$ ls -la .svn
$ rm -f .svn/lock
Тогда
$ svn update
Надеюсь, что это поможет
У меня была точно такая же проблема. Я не мог совершить, и очистка потерпела бы неудачу.
Используя клиент командной строки, я смог увидеть сообщение об ошибке, указывающее, что ему не удалось переместить файл из .svn/props
.svn/prop-base
в .svn/prop-base
.
Я посмотрел на конкретный файл и обнаружил, что он был помечен только для чтения. После удаления атрибута "только для чтения" я смог очистить папку и зафиксировать мои изменения.
Возможно, у вас есть проблема с двумя именами файлов, различающимися только заглавными буквами. Если вы столкнулись с этой проблемой, создание другого каталога рабочей копии не решит проблему.
Текущие файловые системы Windows (т.е. дрянные) просто не замечают разницу между Filename
и FILEname
. У вас есть два возможных исправления:
svn rename -m "broken filename case" http://server/repo/FILEname http://server/repo/filename
Я попытался выполнить svn cleanup
через консоль и получил сообщение об ошибке:
svn: E720002: Can't open file '..\.svn\pristine\40\40d53d69871f4ff622a3fbb939b6a79932dc7cd4.svn-base':
The system cannot find the file specified.
Поэтому я создал этот файл вручную (пустой) и снова svn cleanup
. На этот раз это было сделано хорошо.
Запустите команду svn cleanup
в терминале (если он не работает в Eclipse, как в моем случае):
~/path/to/svn-folder/$ svn cleanup
Я пробовал разные решения, объясненные здесь, но ни один не работал.
Команда действий → Не удается обновить голову:
svn: E155004: в '/home/user/path/to/svn-folder' есть незавершенные рабочие элементы; сначала запустите 'svn cleanup'.
Команда действий → Очистка завершается с той же ошибкой.
Решение, которое сработало для меня: запустите команду svn cleanup в терминале.
Команда выполнена успешно.
Затем команда → Обновление в Eclipse снова заработала.
Примечание: моя версия SVN 1.9.3.
Также проверьте ответ Криса, если svn cleanup
не работает.
Если проблема заключается в чувствительности к регистру (что может быть проблемой при выходе на Mac, а также в Windows), и у вас нет возможности проверить систему * nix, должно работать следующее. Вот процесс с самого начала:
% svn co http://[domain]/svn/mortgages mortgages
(Оформить заказ следует... затем...)
svn: In directory 'mortgages/trunk/images/rates'
svn: Can't open file 'mortgages/trunk/images/rates/.svn/tmp/text-base/Header_3_nobookmark.gif.svn-base': No such file or directory
Здесь SVN пытается извлечь два файла с похожими именами, которые отличаются только регистром - Header_3_noBookmark.gif
и Header_3_nobookmark.gif
. Файловые системы Mac по умолчанию нечувствительны к регистру таким образом, что SVN задыхается в подобных ситуациях. Так...
% cd mortgages/trunk/images/rates/
% svn up
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
Однако запуск svn cleanup
не работает, как мы знаем.
% svn cleanup
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'spacer.gif' is not under version control
spacer.gif
здесь не проблема... Он просто не может перейти от предыдущей ошибки к следующему файлу. Поэтому я удалил все файлы из каталога, кроме .svn
, и удалил журнал SVN. Это заставило очистку работать, так что я мог проверить и переименовать нарушающий файл.
% rm *; rm -rf .svn/log; svn cleanup
% svn up Header_3_nobookmark.gif
A Header_3_nobookmark.gif
Updated to revision 1087.
% svn mv Header_3_nobookmark.gif foo
A foo
D Header_3_nobookmark.gif
% svn up
A spacer.gif
A Header_3_noBookmark.gif
После этого я смог вернуться в корневой каталог проекта и запустить svn up
чтобы проверить остальную часть.
У меня была такая же проблема на 64-битной Windows 7. Я запускал консоль как администратор и удалял каталог .svn из каталога проблем (получил ошибку о журналах или что-то в этом роде, но проигнорировал ее). Затем, в проводнике, я удалил каталог проблем, который больше не отображался под контролем версий. Затем я запустил обновление, и все продолжалось, как ожидалось.
У меня такая же проблема. Для меня причиной стал конфликт с EasySVN и (TortoiseSVN или просто SVN). У меня было автоматическое обновление и коммит с EasySVN (который не работал).
Когда я отключил это, я не смог очистить, зафиксировать или обновить. Ни одно из вышеперечисленных решений не сработало, но перезагрузка сделала :)
Всякий раз, когда у меня возникают подобные проблемы, я использую rsync (примечание: я использую Linux или Mac OS X), чтобы помочь так:
# Go to the parent directory
cd dir_above_borked
# Rename corrupted directory
mv borked_dir borked_dir.bak
# Checkout a fresh copy
svn checkout svn://... borked_dir
# Copy the modified files to the fresh checkout
# - test rsync
# (possibly use -c to verify all content and show only actually changed files)
rsync -nav --exclude=.svn borked_dir.bak/ borked_dir/
# - If all ok, run rsync for real
# (possibly using -c again, possibly not using -v)
rsync -av --exclude=.svn borked_dir.bak/ borked_dir/
Таким образом, у вас есть новая проверка, но с теми же рабочими файлами. Для меня это всегда работает как шарм.
Я столкнулся с этим слишком поздно. Хитрость для меня заключалась в том, что после выбора "Очистить" в диалоговом окне параметров всплывающего окна установите флажок "Снять блокировки", а затем "ОК". Удачно зачищено для меня.
(Прежде чем пытаться перемещать папки и делать новые проверки.)
Удалите папку, в которой находятся .svn
файлы - да, даже папку .svn
, затем выполните svn cleanup
в самой верхней/родительской папке.
Subclipse путается по-настоящему дьявольским действием блокировки Windows. Unlocker является вашим другом. Это может найти заблокированные файлы и принудительно освободить блокировки.
Я столкнулся с той же проблемой. После некоторых поисков в интернете нашел ниже статью. Затем понял, что я вошел как пользователь, отличный от пользователя, которого я использовал для настройки SVN, в основном проблема с разрешениями.
Когда я сталкиваюсь с этой проблемой в TortoiseSVN (Windows), я захожу в Cygwin и запускаю там 'svn cleanup'; он у меня корректно очищается, после чего все работает от TortoiseSVN.
Это может применяться не во всех ситуациях, но когда я недавно столкнулся с этой проблемой, мое "исправление" заключалось в обновлении пакета Subversion в моей системе. Я работал с 1.4.something, и когда я обновился до последней версии (1.6.6 в моем случае), проверка работала.
(Я попытался повторно загрузить его, но извлечение в чистый каталог всегда зависало в одном и том же месте.)
Блокировка только для чтения иногда происходит на сетевых дисках с Windows. Попробуйте отключить и снова подключить его. Затем очистите и обновите.
После просмотра большинства решений, которые здесь приведены, я все еще получал ошибку.
Проблема была без учета регистра OS X. Извлечение каталога, в котором есть два файла с одинаковым именем, но с разной заглавной буквой, вызывает проблему. Например, ApproximationTest.java и Approximationtest.java не должны находиться в одном каталоге. Как только мы избавимся от одного из файлов, проблема исчезнет.
Я столкнулся с проблемой, когда после обновления SVN показывал папку как конфликтующую. Странно, это было видно только через командную строку - TortoiseSVN думал, что все в порядке.
#>svn st
! my_dir
! my_dir\sub_dir
svn cleanup
, svn revert
, svn update
и svn resolve
не смогли исправить это.
В конце концов я решил проблему следующим образом:
После этого все было хорошо.
Обратите внимание, что у меня не было локальных изменений, поэтому я не знаю, рискнул бы ты, если бы сделал. Я не использовал метод удаления/обновления, предложенный другими, - я попал в это состояние, попробовав его в каталоге my_dir/sub_dir/sub_sub_dir (который начинался с тех же симптомов) - поэтому я не хотел рисковать ухудшением ситуации снова!
Не совсем по теме, но, возможно, полезно, если кто-то сталкивается с этим постом, как я.
Нет нет нет! Если вы используете SVN 1.7 или выше, команда очистки должна сделать эту работу!
Я также провел несколько экспериментов и обнаружил, что решением (по крайней мере, в Eclipse) было выполнение очистки только для папки, указанной в сообщении об ошибке, а не для всего проекта!
Я сделал sudo chmod 777 -R.
чтобы иметь возможность изменить разрешения. Без sudo
это не сработало бы, вызывая ту же ошибку, что и другие команды.
Теперь вы можете выполнить svn update
или что-то еще, не выбрасывая весь каталог и не создавая его заново. Это особенно полезно, поскольку в вашей IDE или текстовом редакторе уже могут быть открыты определенные вкладки или возникли проблемы с синхронизацией. Вам не нужно удалять и заменять свой рабочий каталог этим методом.
Я решил эту проблему, скопировав в мою папку какую-то коллегу .svn, а затем обновил свою рабочую копию. Это было хорошее, быстрое и чистое решение.
Ответы мне не помогли, но прежде чем снова проверить проект, я закрыл и открыл Eclipse (Subversive - мой SVN-клиент), и проблема исчезла.
В предыдущем ответе есть несколько очень хороших предложений, но если у вас возникла проблема с TortoiseSVN в Windows (хороший продукт, но...), всегда переходите к командной строке и сначала выполняйте простую "очистку svn".
Во многих случаях клиент Windows не запускает команду очистки, но очистка работает нормально, используя утилиту командной строки SVN.
Несмотря на аналогичную проблему, ручное слияние в представлении синхронизации репозитория помогло решить проблему.
Одно имя файла конфликтовало с другим, и в нем явно упоминалась проблема. Переименование нового файла в другое имя разрешило его.