Как исправить сообщение «Сбой фиксации. Файл 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

О, мальчик! Это выглядит плохо! Единственный вариант, о котором я могу подумать, это то, что рабочая копия повреждена.

Попробуйте удалить рабочую копию, выполнить новую проверку и снова выполнить объединение.

Если это не сработает, зарегистрируйте ошибку.

Answer 2

Была похожая проблема с SVN 1.6.5 на Mac 10.6.5, обновлена ​​до SVN 1.6.9, и фиксация прошла успешно.

Answer 3

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

Мое решение / обходной путь для решения проблемы:

• Я вернул весь пакет
• сначала удалил контент
• зафиксировал удаленный контент
• наконец-то я снова отправил удаленный пакет (и он работал в большинстве случаев: -))

Однако время от времени не удавалось зафиксировать удаленный пакет (который ничего не содержит)

Мой обходной путь:

• Я создал фиктивный класс в пакете
• и после этого я повторил шаги, упомянутые выше

Мой последний намек ...

Но иногда это помогает просто синхронизировать пакет / проект еще раз, и после этого все снова работает отлично.

О моей конфигурации:

• Затмение Неон
• Интерфейс SVN: JavaHL (JNI) 1.8.13 (r1667537)
• Диспетчер серверов VisualSVN, версия: 3.3.1

Может быть, я мог бы помочь кому-то с одним из моих подсказок.

Answer 4

Спасибо, Джейми Баллок, эта работа для меня

Согласно Джейми Баллоку,

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

1. svn update
2. svn разрешено
3. SVN коммит

Answer 5

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

Это возможно?

Answer 6

Это похоже на проблему с выходом свойства svn:mergeinfo между веткой и соединительной линией.

Что приводит к следующим вопросам (простите мои инструкции в командной строке, так как я много использую черепаху):

1. Вы объединяетесь на уровне корневого ствола или на уровне подпапок? По моему опыту, это всегда лучше делать на корневом уровне, таким образом весь ствол думает, что он был объединен, а не просто частью (это, кажется, сильно запутывает svn в 1.5.0)

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

3. Вы слили ствол в ветку до того, как реинтегрировались? Это может помочь устранить конфликты, которые вы можете увидеть при слиянии?

4. Есть ли у вас какие-либо свойства svn:mergeinfo в ветви, которые не находятся на корневом уровне? Я обнаружил, что это всегда вызывает проблемы. Вы всегда можете узнать это, набрав svn -R pg svn:mergeinfo. Затем вы можете записать местоположения и ревизии, которые были ниже корня, если вы находите их релевантными, переместите их в корень с помощью svn merge --record-only -r start:end <location>, а затем удалите их из местоположений подкорня с помощью svn pd svn:mergeinfo <location> Затем вам нужно зафиксировать эти изменения

5. Как только у вас все будет готово, попробуйте снова объединиться.

Answer 7

Видимо SVN не очень надежная программа. У меня была та же проблема (использование SVN с Turtoise), и я решил ее, сохранив содержимое файла .cs и вернувшись на 1 ревизию. Это показало конфликты вот так: "<<<<<<< имя файла мои изменения </p>

======= код слит из репозитория редакция "

пока я ничего особенного не сделал (только однажды вернул ревизию).

Я заменил содержимое этого файла сохраненным содержимым, сохранил его, а затем выбрал через TortoiseSVN → Решено. Затем я могу зафиксировать изменения в хранилище.

Answer 8

Ух, этот вопрос занял у меня некоторое время, так как я использовал SVN через Eclipse. В конце концов, единственное, что мне помогло, - это зафиксировать все незатронутые файлы, затем (с закрытым Eclipse) переименовать каталог проекта и повторно проверить проект из SVN. Рад, что теперь он работает правильно!

Answer 9

Я сомневаюсь, но, возможно, запуск очистки svn в вашем рабочем каталоге поможет.

Answer 10

Я столкнулся с той же проблемой, разбил голову и обнаружил, что я изменил каталог в хранилище с "/" на "/ trunk" и забыл выполнить команду "Switch" в TortoiseSVN!