Що робити, коли помилка svn не вдається?

У мене багато змін у робочій папці, і щось викрутилося, намагаючись зробити оновлення.

Тепер, коли я видаю 'svn очищення', я отримую:

>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, і воно повинно привести ваш новий частковий каталог .svn у швидкість зі старим робочим каталогом.

Це все трохи заплутано, обробляти мудро. По суті, ми робимо це видалення пошкодженого .svn, а потім створення нового .svn для того ж шляху оформлення замовлення. Потім ми переміщуємо цей новий .svn до старого робочого каталогу та оновлюємо його до репо.

Я щойно робив це в TSVN, і, здається, працює добре і не вимагає повного оформлення замовлення та завантаження.

-Джоді

Подивись на

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

Короткий зміст виправлення зверху (спасибі Аную Варму)

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 зберігає свою інформацію в папці (in .svn), тому якщо ви просто маєте справу з підпапками, вам не потрібен огляд всього сховища - лише папка, яка зашифрована:

cd dir_above_borked
mv borked_dir borked_dir.bak
svn update borked_dir

Це дасть вам хорошу робочу копію папки, що працює, але ви все ще маєте резервну копію змін у 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 очищення'.

Дія команда → Прибирання не вдається з тією ж помилкою.

Рішення, яке працювало для мене: запустіть команду очищення svn в терміналі .

Команда вдалася.

Потім команда → Оновлення в затемненні знову запрацювала.

Примітка: моя версія 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-розрядному. Я запустив консоль як адміністратор і видалив каталог .svn з каталогу проблем (отримав помилку щодо журналів чи чогось, але проігнорував його). Потім, в Explorer, я видалив каталог проблем, який більше не відображався як під контролем версій. Потім я запустив оновлення, і все пройшло так, як очікувалося.

Якщо проблема полягає у чутливості до регістру (що може бути проблемою при переході на 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 (NB: я використовую 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/

Таким чином у вас є свіжа каса, але з тими ж робочими файлами. Для мене це завжди працює як шарм.

Я наткнувся на це теж недавно. Хитрість для мене полягала в тому, що виберіть "Очистити", у діалоговому вікні параметрів спливаючого вікна встановіть прапорець "Перервати блокування", а потім "ОК". Це вдало очистило мене.

Субкліп заплутається в дійсно диявольській поведінці блокування Windows. Unlocker - ваш друг. Тут можна знайти заблоковані файли та примусово звільнити блоки.

(Перш ніж спробувати перемістити папки та зробити новий замовлення.)

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

Я зіткнувся з тим же питанням. Після деяких пошуків в Інтернеті знайшли нижченаведену статтю . Потім зрозумів, що я був зареєстрований як користувач, відмінний від користувача, який я використовував під час налаштування SVN, в основному проблема дозволу.

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

Відповіді тут не допомогли мені, але перш ніж перевірити проект ще раз, я закрив і відкрив Eclipse (Subversive - мій клієнт SVN), і проблема зникла.

Це може застосовуватися не у всіх ситуаціях, але коли я нещодавно зіткнувся з цією проблемою, моїм "виправленням" було оновлення пакета Subversion на моїй системі. Я працював 1.4.щось, і коли я оновив до останнього (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.

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

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