Что делать при сбое svn cleanup?

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

Теперь, когда я запускаю '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 1.7 все изменилось, и популярное решение удаления файла журнала в каталоге .svn не представляется возможным при переходе к реализации рабочей копии базы данных.

Вот то, что я сделал, казалось, сработало:

1. Удалите каталог .svn для вашей рабочей копии.
2. Начать новый заказ в новой временной директории.
3. Отмените заказ (мы не хотим ждать, пока все будет снято).
4. Запустите очистку этой отмененной проверки.
5. Теперь у нас есть новый каталог .svn с чистой базой данных (хотя нет / несколько файлов)
6. Скопируйте этот .svn в ваш старый, поврежденный рабочий каталог.
7. Запустите svn update, и он должен привести ваш новый частичный каталог .svn в соответствие с вашим старым рабочим каталогом.

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

Я только что сделал это в ЦВН, и он, кажется, работает нормально и не требует полной проверки и загрузки.

-Jody

Взгляни на

http://www.anujvarma.com/svn-cleanup-failedprevious-operation-has-not-finished-run-cleanup-if-it-was-interrupted/

Сводка исправления сверху ссылка (спасибо Anuj Varma)

1. Установите оболочку командной строки sqlite (sqlite-tools-win32) с http://www.sqlite.org/download.html

2. sqlite3 .svn/wc.db "select * from work_queue"

SELECT должен показать вам вашу папку / файл, который вас обидел, как часть рабочей очереди. Что вам нужно сделать, это удалить этот элемент из рабочей очереди.

3. sqlite3 .svn/wc.db "delete from work_queue"

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

Если все остальное терпит неудачу:

1. Проверьте в новую папку.
2. Скопируйте ваши измененные файлы.
3. Возвращайтесь.
4. Заархивируйте старую папку куда-нибудь (вы никогда не знаете, + паранойя - это хорошо), прежде чем удалить ее и использовать новую.

Последняя версия (я использую 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.

Я посмотрел на конкретный файл и обнаружил, что он был помечен только для чтения. После удаления атрибута «только для чтения» я смог очистить папку и зафиксировать мои изменения.

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

Современные файловые системы Windows (т.е. дрянные) просто не понимают разницу между Filenameи FILEname. У вас есть два возможных исправления:

1. Проверьте на платформе с реальной файловой системой (на основе Unix), переименуйте файл и зафиксируйте изменения.
2. Когда вы загружены в Windows, вы можете переименовывать файлы в обозревателе хранилища Eclipse SVN, который распознает разницу и переименовывает файл там.
3. Вы можете переименовывать проблемные файлы также удаленно из любого клиента командной строки SVN, используя svn rename -m "broken filename case" http://server/repo/FILEname http://server/repo/filename

Запустите 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не работает.

Я пытался сделать svn cleanupчерез консоль и получил ошибку, как:

svn: E720002: Can't open file '..\.svn\pristine\40\40d53d69871f4ff622a3fbb939b6a79932dc7cd4.svn-base':
The system cannot find the file specified.

Поэтому я создал этот файл вручную (пустой) и сделал svn cleanupснова. На этот раз это было сделано хорошо.

У меня такая же проблема. Для меня причиной стал конфликт с EasySVN и (TortoiseSVN или просто SVN). У меня было автоматическое обновление и коммит с EasySVN (который не работал).

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

У меня была такая же проблема на Windows 7 64-bit. Я запустил консоль как администратор и удалил каталог .svn из проблемного каталога (получил ошибку в журналах или что-то в этом роде, но проигнорировал ее). Затем в проводнике я удалил проблемный каталог, который больше не показывался как под управлением версиями. Затем я запустил обновление, и все пошло так, как ожидалось.

Если проблема заключается в чувствительности к регистру (что может быть проблемой при выходе на 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чтобы проверить остальную часть.

Всякий раз, когда у меня возникают подобные проблемы, я использую 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/

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

Я столкнулся с этим слишком поздно. Хитрость для меня заключалась в том, что после выбора «Очистить» в диалоговом окне параметров всплывающего окна выберите «Снять блокировки», а затем «ОК». Удачно зачищено для меня.

Subclipse смущает по-настоящему дьявольское поведение блокировки Windows. Unlocker твой друг. Это может найти заблокированные файлы и принудительно снять блокировки.

(Прежде чем пытаться перемещать папки и делать новые проверки.)

Удалите папку, в которой находятся поврежденные файлы, - да, даже .svnпапку, затем сделайте ее svn cleanupв самой верхней / родительской папке.

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

Когда я сталкиваюсь с этой проблемой в TortoiseSVN (Windows), я захожу в Cygwin и оттуда запускаю ' svn cleanup '; он у меня корректно очищается, после чего все работает от TortoiseSVN.

Ответы здесь не помогли мне, но перед повторной проверкой проекта я закрыл и открыл Eclipse (Subversive - мой клиент SVN), и проблема исчезла.

Это может применяться не во всех ситуациях, но когда я недавно столкнулся с этой проблемой, мое «исправление» заключалось в обновлении пакета 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 все они были неудачными при фиксации этого.

В конце концов я решил проблему следующим образом:

• Посмотрите в каталоге .svn "sub_dir"
• Используйте RC -> Свойства, чтобы снять флажок «только для чтения» в файле записей
• Откройте файл записей и удалите строку «незакончено ...» и соответствующую контрольную сумму
• Сохраните и снова включите флаг только для чтения.
• Повторите для каталога my_dir

После этого все было хорошо.

Обратите внимание, что у меня не было локальных изменений, поэтому я не знаю, рискнул бы ты, если бы сделал. Я не использовал метод удаления / обновления, предложенный другими, - я попал в это состояние, попробовав его в каталоге my_dir / sub_dir / sub_sub_dir (который начинался с тех же симптомов) - поэтому я не хотел рисковать ухудшением ситуации очередной раз!

Не совсем по теме, но, возможно, полезно, если кто-то сталкивается с этим постом, как я.

Нет нет нет! Если вы используете SVN 1.7 или выше, команда очистки должна сделать эту работу!

Я также провел несколько экспериментов и обнаружил, что решением (по крайней мере, в Eclipse ) было выполнение очистки только для папки, указанной в сообщении об ошибке, а не для всего проекта!

Я сделал, sudo chmod 777 -R .чтобы иметь возможность изменить разрешения. Без sudoэтого это не сработало бы, выдавая ту же ошибку, что и другие команды.

Теперь вы можете делать svn updateчто угодно, не выбрасывая весь каталог и не создавая его заново. Это особенно полезно, поскольку в вашей IDE или текстовом редакторе уже могут быть открыты определенные вкладки или возникли проблемы с синхронизацией. Вам не нужно удалять и заменять ваш рабочий каталог этим методом.

Я решил эту проблему, скопировав каталог моего коллеги .svn в мою, а затем обновив свою рабочую копию. Это было хорошее, быстрое и чистое решение.

В предыдущем ответе есть несколько очень хороших советов, но если у вас возникла проблема с TortoiseSVN в Windows (хороший продукт, но ...), всегда возвращайтесь к командной строке и сначала выполняйте простую «очистку svn».

Во многих случаях клиент Windows не будет запускать команду очистки, но очистка работает нормально, используя утилиту командной строки SVN.

Несмотря на аналогичную проблему, ручное слияние в представлении синхронизации репозитория помогло решить проблему.

Одно имя файла конфликтовало с другим, и в нем явно упоминалась проблема. Переименование нового файла в другое имя разрешило его.