Как исправить сообщение «Сбой фиксации. Файл xxx устарел. Путь xxx не найден».

Question

Недавно я столкнулся с особенно неприятной проблемой, связанной с фиксацией результата слияния в Subversion. Наш сервер Subversion @ 1.5.0, а мой клиент TortoiseSVN теперь @ 1.6.1.

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

Commit failed (details follow):
File 
'flex/src/com/penbay/invision/portal/services/http/soap/ReportServices/GetAllBldgsParamsByRegionBySiteResultEvent.as' 
is out of date
'/svn/ibis/!svn/wrk/531d459d-80fa-ea46-bfb4-940d79ee6d2e/visualization/trunk/source/flex/src/com/penbay/invision/portal/services/http/soap/ReportServices/GetAllBldgsParamsByRegionBySiteResultEvent.as' 
path not found
You have to update your working copy first.

Мой рабочий багажник обновлен. Я даже извлек новую в другую папку, чтобы убедиться, что слияние не связано с каким-либо локальным беспорядком. Я провел еще несколько исследований по этому вопросу, и я думаю, что частью проблемы является ошибка пользователя. Я думаю, что наши проблемы:

1. Некоторые разработчики работали с клиентом Subversion до 1.5, а некоторые после. Я считаю, что это может испортить информацию о слиянии.
2. В других ветках мы выполнили частичные слияния. То есть мы не всегда выполняем слияния в корне ветки. Это должно было облегчить обновление усилий Flex и .NET в пределах одной ветви.
3. Мы выполнили циклические (рефлексивные) слияния в нашей ветке. Это было сделано, потому что у нас было несколько параллельных ветвей, и мы хотели периодически обновлять нашу ветку последним кодом в транке.

Все эти вещи явно не рекомендуются книгой / командой Subversion. Мы усвоили наш урок и теперь знаем лучшие практики. Однако сначала нам нужно объединить и зафиксировать нашу последнюю ветку.

Какой лучший способ исправить проблемы, с которыми мы сталкиваемся?

Будет ли удаление всей информации о слиянии в стволе и ответвлении жизнеспособным решением? Нет. Я сделал это, но это не устраняет ошибку, которую я получаю выше.

Answer 1

У меня просто была эта проблема, и причина, казалось, была в том, что каталог был помечен как конфликтующий. Исправить:

svn update
svn resolved <the directory in conflict>
svn commit

Answer 2

Я получал это на сервере 1.6.2, черепаха 1.6.8. Все в Windows, нет слияния в этой ветке.

Я переименовал каталог и каким-то образом (возможно, из-за AnkhSVN) два файла в каталоге были помечены как «замененные», а не как «нормальные». Были некоторые дополнительные незначительные изменения в других файлах в каталоге.

Восстановление файлов, помеченных как замененные, устранило проблему.

Answer 3

У меня тоже была такая же проблема, и я решил эту же проблему следующим способом

svn resolve --accept=working <FILE/FOLDER NAME>
svn cleanup
svn update <FILE/FOLDER NAME>
svn commit <FILE/FOLDER NAME> -m "Comment"

Надеюсь, это поможет вам:)

Answer 4

У меня только что была похожая проблема, но без каких-либо ветвлений или слияний, чтобы вызвать проблему. Мой обходной путь был:

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

Теперь все в порядке.

Answer 5

У меня была такая же проблема при попытке зафиксировать мою рабочую копию. Я добавил папку, которую Subversion сообщает как «путь не найден», в список игнорируемых. Фиксация (должна быть успешной). Затем добавьте эту же папку обратно в Subversion. Подтвердите снова.

Answer 6

Я знаю, что это старый пост, но эта проблема все еще встречается довольно часто. Самый простой способ, который я нашел, - это переименовать / удалить файл .svn / all-wcprops в уязвимой папке, затем запустить обновление и зафиксировать.

Answer 7

У меня была такая же проблема сегодня, и я не сделал никаких промежуточных слияний, поэтому из вашего вступительного поста может применяться только # 1 - однако я сделал коммиты как из svn-клиента в ubuntu, так и из tortoisesvn в windows. К счастью, в моем случае не было никаких изменений в стволе, поэтому я мог просто заменить ствол на ветку. Возможно разные версии SVN тогда? Это очень беспокоит.

Если вы используете функции перемещения / копирования / удаления svn, хотя в моем случае история не теряется - я svn переместил ствол, а затем svn переместил ветку в ствол.

Answer 8

У меня была такая же проблема, не знаю, в чем причина, но я исправил, набрав в терминале

svn update

и затем я фиксирую и бум это работает!

Answer 9

У меня была такая же проблема после слияния ветки с кучей изменений обратно в мой ствол. Единственные два решения, которые я видел, - это решение svn move, предлагаемое Pacifika , или ручное объединение файлов с помощью инструмента diff Но я нашел обходной путь ...

На машине, которая не работала, был запущен клиент Subversion 1.6.5. Я сделал то же самое на машине с Subversion 1.5.4, и она сработала ! На обеих машинах я сделал 1) чистую проверку ствола, 2) svn merge ... и 3) svn commit. Мой сервер стоит 1.5.x, что стоит.

Надеюсь, это кому-нибудь поможет.

Answer 10

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

Я удалил все файлы в транке и зафиксировал эти изменения. Затем я экспортировал свой код ветки в ствол, добавил все файлы и сделал большой коммит. Это имело эффект того, что мой ствол имитировал мою ветку 1: 1 (что я и хотел в любом случае).

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

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