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

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

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

30 ответов


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


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

в двух словах, фокус в том, чтобы перейти к .каталог СВН (в каталоге, содержащем файл-нарушитель) и удалить файл "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 и т. д... chosing mf (мой полный) гарантирует, что ничего не перезаписывается, и я мог бы совершить, когда это сделано.

Джей CompuMatter


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


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

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

должно работать нормально


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

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 .гитюдного ."в первый раз. Удаление. 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, это, вероятно, потому, что что-то изменилось на стороне GitHub. Решение простое, вам просто нужно запустить svn switch, что позволяет ему правильно найти себя, а затем обновить, и все будет работать. Просто запустите следующее из корня вашего checkout

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 может вызвать эту проблему.


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


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


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


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


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

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

для решения проблемы необходимо обновить сервер и клиенты. См. соответствующую запись примечаний к выпуску Subversion 1.9: "устаревшие" ошибки при совершении более HTTPv1.


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


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

В Eclipse > Окно > Показать Панель > история Я видел, что файл не находится в новейшей версии, хотя я сделал несколько svn "Override & Update" / "Revert" / delete file и checkout.

поэтому я пошел Package Explorer > щелкните правой кнопкой мыши на файле > заменить на > последние из репозитория.

Другой Взгляд в представлении истории показал, что файл теперь о последней редакции.


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

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


Я получил эту ошибку при попытке зафиксировать некоторые файлы, только это был файл / папка, которая не существовала в моей рабочей копии. Я действительно не хотел проходить через хлопоты перемещения файлов и перепроверки, в конце концов, я закончил редактирование .svn / entries file и удалил оскорбительную ссылку на каталог.


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


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


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


просто сделайте svn в командной строке или, если вы находитесь в windows, выберите опцию обновления svn.

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

я только что получил это, когда я пытался commit с . Я вытащил branches/branch-1 в master с GitHub. Делать svn update из родительского каталога (то есть корня моей рабочей копии) вместо trunk Кажется, что-то сделал в branches кроме trunk. Когда я пытался commit опять же, ошибки не было.

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

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


"очистить" это поможет вам на пути.

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