Я пытаюсь переместить структуру каталогов из одного места в другое в Subversion, но получаю ошибку Item '*' is out of date commit.
У меня последняя версия проверена (насколько я могу судить). svn st -u не вызывает различий, отличных от команд mv.
Я иногда получаю это с TortoiseSVN на окнах. Решение для меня - это svn update каталог, хотя нет никаких изменений для загрузки или обновления. Он делает что-то для метаданных, которые магически исправляют его.
После прочтения всех очевидных вещей и некоторых других предложений здесь, без всякой удачи, поиск Google привел к этой ссылке (ссылка больше не работает) - Subversion говорит: Возможно, ваш файл или каталог устарели
Вкратце, трюк заключается в том, чтобы перейти в каталог .svn (в каталоге, который содержит файл-нарушитель), и удалить файл "all-wcprops" .
Работал для меня, когда ничего другого не делал.
Я считаю, что эта проблема исходит из файла .svn. Это либо неверно в старой родительской, либо новой родительской, либо старой. Я бы попытался вернуться к исходной точке. Используйте экспорт, чтобы получить чистую копию папки. Переместите чистую копию в новое место и используйте команду add и delete для перемещения. Это вручную делает то, что делает SVN, но может работать.
Я обнаружил, что это работает для меня:
svn update
svn resolved <dir>
svn commit
Пробовал обновлять локальную копию и возвращать данный предмет и все еще получил ошибку "устаревший". Это работало по какой-то причине:
svn update --force /path/to/dir/or/file
У меня была такая же проблема в нескольких папках, и это то, что я сделал для совершения:
1) В перспективе "Team Synchronize" щелкните правой кнопкой мыши по папке > "Переопределить и обновить"
2) Удалить папку снова
3) Зафиксируйте и будьте счастливы
Спасибо. Это просто разрешило это для меня. svn update --force/path to filename/
Если ваш последний файл в локальном каталоге тот же, никаких подсказок нет. Если файл отличается, он запрашивает tf, mf и т.д. Chosing mf (my full) гарантирует, что ничто не перезаписывается, и я мог бы выполнить, когда это было сделано.
Jay CompuMatter
Мне удалось решить эту проблему, нажав кнопку обновления
Как говорит Александр-Клюбин, сделайте ход в репозитории. Это также будет намного быстрее, особенно если у вас есть большой объем данных для перемещения, потому что вам больше не придется передавать все эти данные по сети.
svn mv https://[email protected]/svn/old/ https://[email protected]/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-реквизит, созданный при запуске "svn propset svn: ignore -F .gitignore". в первый раз. Удаление .svn/dir-реквизитов кажется плохой идеей и может привести к другим ошибкам, поэтому лучше всего использовать "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, который позволяет ему правильно найти себя, затем обновить и все будет работать. Просто запустите следующее из корня вашей проверки
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 удалил глупый каталог, а затем зафиксировал его. Когда я попытался добавить папку с моей локальной машины, она STILL выбрала ошибку (перемещение SVN делало то же самое, когда я пытался переименовать эту папку). Поэтому я вернулся, затем сделал mkdir DIRNAME, добавил и сделал. Затем я добавил содержимое и зафиксировал его, и он сработал.
Я случайно получил эту ошибку после удаления нескольких каталогов, содержащих некоторые файлы. Я удалил каталоги через Netbeans и понял, что на самом деле они не удалили их. Казалось, что просто удалил все внутри каталогов и удалил ссылку на каталог в Netbeans. Тем не менее, они все еще существуют в файловой системе. Убедитесь, что они удалены из файловой системы и повторите попытку.
Если когда-то была решена аналогичная проблема, просто проверив новую рабочую копию и заменив каталог .svn, сбросив ошибки фиксации с помощью этой недавно проверенной. Причина в моем случае заключалась в том, что после повреждения хранилища и восстановления из резервной копии рабочая копия указывала на версию, которая не существовала в восстановленном репозитории. Также получили ошибки "устаревшие вещи". Обновление рабочей копии до фиксации не решило этого, но заменил .svn, как описано выше.
Я сделал это, и это сработало для меня:
1. Возьмите резервную копию файла. Вы можете просто скопировать код в текстовый файл.
2. Щелкните правой кнопкой мыши файл, который вы хотите совершить → Команда → Показать историю.
3. В панели "Показать историю" вы увидите все изменения этого файла. Щелкните правой кнопкой мыши по последней версии файла → Get Revision: он переопределит ваши локальные изменения.
4. Теперь объедините свой код с последним файлом с резервным файлом (шаг №1).
5. Синхронизируйте и запишите новый объединенный файл.
Обновите свой сервер и клиент до Subversion 1.9.
Если ошибка out of date случайным образом возникает, когда она обычно не должна, при запуске commit она может указывать на то, что вы используете устаревший и неподдерживаемый клиент или сервер Subversion 1.7 или старше.
Вы должны обновить сервер и клиенты, чтобы решить проблему. См. Соответствующую запись Subversion 1.9 Release Notes: "Устаревшие" ошибки при передаче через HTTPv1.
Ошибка в том, что вы не обновили этот конкретный файл, сначала обновите, а затем можете только зафиксировать файл.
Пробовал все, кроме изменения в .svn напрямую. Ничто так не помогло мне в этом решении.
В Eclipse > Окно > Показать представление > История Я видел, что этот файл не находится в новейшем редакторе, хотя я сделал несколько svn "Переопределить и обновить" / "Восстановить" /удалить файл и проверка.
Итак, я отправил Package Explorer > Щелкните правой кнопкой мыши на файле > Заменить с помощью > Последний из репозитория.
Еще один вид в представлении истории показал, что файл находится в последней версии.
Это произошло, когда я обновил ветвь более ранней версии с файлами из магистрали. Я использовал проводник Windows для копирования папок из папки проверки багажника и вставлял их в свое представление Eclipse папки проверки выпуска ветки. Теперь Windows Explorer был настроен так, чтобы не показывать "скрытые" файлы, начинающиеся с ".", Поэтому я не обращал внимания на все неправильные файлы .svn, вставленные в мою папку проверки выпуска. Doh!
Мое решение состояло в том, чтобы снести поврежденный проект Eclipse, проверить его снова, а затем скопировать новые файлы более тщательно. Я также изменил Windows, чтобы показать "скрытые" файлы.
Я получил эту ошибку при попытке зафиксировать некоторые файлы, только это был файл/папка, которая не существовала в моей рабочей копии. Я ДЕЙСТВИТЕЛЬНО не хотел перебирать проблемы с перемещением файлов и перепроверять, в конце концов, я закончил редактирование файла .svn/entries и удалил ссылку на нарушающий каталог.
В моем случае единственным решением было удаление локальной версии и повторная проверка новой копии.
Я только что получил эту ошибку. Я рекомендую вам сначала проверить ваш сервер, если исходный файл есть. Иногда изменения не производятся в вашей локальной папке. Если это ваша ситуация, просто удалите свою папку и проверку еще раз.
Чтобы решить проблему, мне нужно было вернуть файл с проблемой и обновить рабочую копию, а затем я снова изменил файл, и после этих шагов ошибка больше не возникала.
Просто выполните команду svn в командной строке или, если вы находитесь в Windows, выберите параметр обновления svn.
Я просто получил это, пока я пытался commit из каталога trunk. Выполнение svn update из каталога trunk не решило ошибку; однако выполнение svn update из родительского каталога (где принадлежит каталог .svn) действительно разрешило ошибку.
Мое предположение о том, что произошло (вариант использования среди других, может быть несколько причин для этого "svn: E160024: ресурс устаревший, попробуйте обновить" ): до trunk был каталог branches, Я вытащил branches/branch-1 в master из GitHub. Выполнение svn update из родительского каталога (т.е. Корня моей рабочей копии) вместо trunk похоже, что-то сделано в branches в дополнение к trunk. Когда я снова попытался commit, ошибки не было.
Однако, как я сказал выше, это один из примеров среди многих других.
Примечание: в отличие от того, что предложил кто-то, я не считаю, что неплохо играть вручную в каталоге .svn.
более isyly сделать это:
1) Я скопирую код модификации в блокнот. 2) затем обновите файл. 3) скопируйте код блокнота в обновленном файле. 4) совершить в svn.