Как вы преодолеваете svn 'устарела' ошибка?

Я пытался переместить структуру каталогов из одного места в другое в Subversion, но я получаю Item '*' is out of dateошибку фиксации.

Я проверил последнюю версию (насколько я могу судить). svn st -uне появляется никаких отличий, кроме команд mv.

Я иногда получаю это с TortoiseSVN на окнах. Решением для меня является svn updateкаталог, даже если нет версий для загрузки или обновления. Это делает что-то с метаданными, что волшебным образом исправляет это.

Попробовав все очевидные вещи и некоторые другие предложения здесь, без какой-либо удачи, поиск Google привел к этой ссылке (ссылка больше не работает) - Subversion говорит: Ваш файл или каталог, вероятно, устарели

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

Работал на меня, когда больше ничего не делал.

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

Я обнаружил, что это работает для меня:

svn update
svn resolved <dir>
svn commit

Попытался обновить локальную копию и отменить рассматриваемый элемент, но все равно получил ошибку «устарел». Это сработало по какой-то причине:

svn update --force /path/to/dir/or/file

У меня была одна и та же проблема в нескольких папках, и это то, что я сделал для фиксации:

1) В перспективе «Team Synchronize» щелкните правой кнопкой мыши папку> «Переопределить и обновить».
2) Удалите папку еще раз.
3) Примите и будьте счастливы.

Спасибо. Это только что решило это для меня. svn update --force / путь к имени файла /

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

Джей CompuMatter

Мне удается решить эту проблему, нажав кнопку обновления

Как говорит @ Александр-Клюбин, сделайте переезд в хранилище. Это также будет намного быстрее, особенно если у вас есть большой объем данных для перемещения, потому что вам не придется снова передавать все эти данные по сети.

svn mv https://username@server/svn/old/ https://username@server/svn/new/

должно работать просто отлично

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

sudo rm -r /path/to/dir/

после :

svn up and commit or delete 

Вы уверены, что проверили голову, а не более низкую ревизию? Кроме того, вы сделали обновление, чтобы убедиться, что вы получили последнюю версию?

Есть обсуждение этого на http://svn.haxx.se/users/archive-2007-01/0170.shtml .

Выполните перемещение прямо в хранилище.

Существует как минимум еще одна причина ошибки «устарела». В моем случае проблема заключалась в .svn / dir-props, который был создан с помощью команды "svn propset svn: ignore -F .gitignore". в первый раз. Удаление .svn / dir-props кажется плохой идеей и может вызвать другие ошибки, поэтому может быть лучше использовать «svn propdel» для очистки ошибочного «svn propset».

# Normal state, works fine.
> svn commit -m"bump"  
Sending        eac_cpf.xsl
Transmitting file data .
Committed revision 509.

# Set a property, but forget to commit.
> svn propset svn:ignore -F .gitignore .
property 'svn:ignore' set on '.'

# Edit a file. Should have committed before the edit.
> svn commit -m"bump"                   
Sending        .
svn: Commit failed (details follow):
svn: File or directory '.' is out of date; try updating
svn: resource out of date; try updating

# Delete the property.
> svn propdel svn:ignore .              
property 'svn:ignore' deleted from '.'.

# Now the commit works fine.
> svn commit -m"bump"     
Sending        eac_cpf.xsl
Transmitting file data .
Committed revision 510.

Если вы используете github svn bridge, это скорее всего потому, что что-то изменилось на стороне github. Решение простое, вам просто нужно запустить svn switch, что позволяет ему правильно найти себя, затем обновить, и все будет работать. Просто запустите следующее из корня вашей проверки

svn info | grep Relative 
svn switch path_from_previous_command
svn update

или

svn switch `svn info | grep Relative | sed 's_.*: __'`
svn update

Основа для этого решения взята из блога Ли Преймсбергера.

Вы перемещаете это, используя svn mv, или просто mv? Я думаю, что использование только mvможет вызвать эту проблему.

Я переместил каталог на свою локальную машину для сохранности, затем svn удалил тупой каталог, а затем зафиксировал. Когда я пытался добавить папку с моего локального компьютера, она все равно выдавала ошибку (перемещение SVN делало то же самое, когда я пытался переименовать папку). Так что я вернулся, затем я сделал MKDIR DIRNAME, добавил и совершил. Затем я добавил содержимое и зафиксировал, и это сработало.

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

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

Я сделал это, и это сработало для меня:
1. Сделайте резервную копию вашего файла. Вы можете просто скопировать свой код в текстовый файл.
2. Щелкните правой кнопкой мыши файл, который вы хотите зафиксировать >> Команда >> Показать историю. 3. На панели «Показать историю» вы увидите все ревизии этого файла. Щелкните правой кнопкой мыши последнюю версию файла >> Получить версию: она отменит ваши локальные изменения.
4. Теперь объедините ваш код с последним файлом с файлом резервной копии (шаг № 1).
5. Синхронизировать и зафиксировать вновь объединенный файл.

Обновите ваш сервер и клиент до Subversion 1.9.

Если out of dateошибка возникает случайно, когда это обычно не происходит, при запуске commit, это может указывать на то, что вы используете устаревший и неподдерживаемый Subversion 1.7 или более старый клиент или сервер.

Вы должны обновить сервер и клиенты, чтобы решить проблему. См. Соответствующую запись Subversion 1.9 Release Notes: «Устаревшие» ошибки при фиксации через HTTPv1 .

Ошибка в том, что вы не обновили этот конкретный файл, сначала обновите, а затем только вы можете зафиксировать файл.

Перепробовал все, кроме изменения в .svn напрямую. Ничего не помогло, так вот мое решение.

В Eclipse> Window> Show View> History я видел, что файл не в последней редакции, хотя я сделал несколько SVN «Переопределить и обновить» / «Восстановить» / удалить файл и оформить заказ.

Итак, я выбрал Package Explorer> Щелкните правой кнопкой мыши на файле> Заменить на> Последние из репозитория .

Еще один просмотр в режиме просмотра истории показал, что файл был на последней редакции.

«Очистить», вы получите на ходу.

Щелкните правой кнопкой мыши папку svn и нажмите «Очистить», сделайте это, если вы получите эту ошибку.

Это произошло, когда я обновил ветку более раннего выпуска файлами из ствола. Я использовал Windows Explorer для копирования папок из папки извлечения ствола и вставил их в представление Eclipse папки извлечения ветки релиза. Теперь проводник Windows был настроен так, чтобы не показывать «скрытые» файлы, начинающиеся с «.», Поэтому я не обращал внимания на то, что все неправильные файлы .svn были вставлены в папку извлечения моей ветки релиза. Doh!

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

я получил эту ошибку при попытке зафиксировать некоторые файлы, только это был файл / папка, которой не было в моей рабочей копии. Я ДЕЙСТВИТЕЛЬНО не хотел преодолевать трудности, связанные с перемещением файлов и перепроверкой, в конце концов я закончил редактировать файл .svn / records и удалил неправильную ссылку на каталог.

В моем случае решением было только удаление локальной версии и повторная проверка свежей копии.

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

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

Просто введите svn в командную строку или, если вы находитесь в Windows, выберите опцию svn update.

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

Я только что получил это, когда я пытался commitиз trunkкаталога. Выполнение svn updateиз trunkкаталога не решило ошибку; однако выполнение svn updateиз родительского каталога (к которому .svnотносится каталог) действительно решило ошибку.

Мое предположение о том, что произошло (среди прочего, случай использования, может быть несколько причин для этого «svn: E160024: ресурс устарел; попробуйте обновить»): наряду с trunkэтим был branchesкаталог. Я вытащил branches/branch-1в masterGitHub. Работа svn updateс родительским каталогом (то есть с корнем моей рабочей копии) вместо того trunk, чтобы, кажется, что-то сделала branchesв дополнение к trunk. Когда я попытался commitснова, не было ошибки.

Однако, как я уже сказал выше, это один случай среди многих других.

Примечание: в отличие от того, что кто-то предложил, я не думаю, что это хорошая идея, чтобы играть вручную в .svnкаталоге.