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

Question

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

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

Answer 1

Существует как минимум еще одна причина ошибки «устарела». В моем случае проблема заключалась в .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.

Answer 2

Если вы используете 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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

«Очистить» Это поможет вам.

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

Answer 9

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

В Eclipse> Окно> Показать представление> История Я видел, что файл не в последней редакции, хотя я сделал несколько SVN "Переопределить и обновить" / "Вернуть" / удалить файл и оформить заказ .

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

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

Answer 10

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