Как мне исправить «Commit Failed. Файл xxx устарел. XXX путь не найден.

Недавно я столкнулся с особенно острой проблемой, связанной с фиксацией результата слияния в 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. Мы усвоили наш урок и теперь знаем лучшие практики. Однако сначала нам нужно объединить и зафиксировать нашу последнюю ветку.

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

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

4.05.2009 12:32:48
20 ОТВЕТОВ
РЕШЕНИЕ

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

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

2
14.07.2009 13:40:08
Я должен был сделать это также, однако, учитывая, что это произошло во время кризиса, я неправильно экспортировал свою ветку в транк и зафиксировал изменения, таким образом потеряв историю. К счастью, я не испытывал этой проблемы с тех пор.
Ryan Taylor 14.07.2009 20:39:54
Я думаю, что ответ @ simon-d ниже является реальным решением. Это больше похоже на обходной путь :)
Diego F. Durán 15.09.2011 13:39:26

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

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

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

1
4.05.2009 17:05:33
Это выглядит довольно плохо. Я пытался выполнить новые проверки, но еще не повезло. К сожалению, на данный момент мой единственный выход, кажется, состоит в том, чтобы удалить все файлы в моем стволе, экспортировать ветвь в папку ствола и повторно добавить все необходимые файлы.
Ryan Taylor 4.05.2009 17:37:11

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

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

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

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

1
4.05.2009 20:55:50

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

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

0
2.06.2009 17:33:27
Никто не редактировал в багажнике. Обычно редактирование в транке запрещено, так как мы используем стабильный метод транка. Поскольку мы решили начать с нуля, как и в ответе выше, я боюсь, что никогда не узнаю истинную причину проблемы.
Ryan Taylor 3.06.2009 02:33:17

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

4
24.07.2009 13:26:42
Спасибо @David, гораздо более простое решение, чем некоторые из обходных путей в сети
Jonathan Day 9.09.2011 07:53:12

Это похоже на проблему с 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. После того, как вы сделали все, попробуйте снова объединиться.

0
24.07.2009 13:54:54
1. Мы делали частичные слияния. Мы прекратили эту практику. Хотя мы все еще создаем ветки из подкаталога транка. 2. Мы редко можем заставить работать опцию --reintegrate. Я забыл ошибку, которую мы получили в данный момент. Мы переключились, чтобы указать ревизии, которые мы хотим объединить, чтобы избежать этой ошибки. 3. В общем случае мы объединяем магистраль с веткой перед любым объединением обратно в магистраль, поэтому мы можем разрешить проблемы слияния в ветке. 4. Похоже, не было никаких проблем со свойствами svn: mergeinfo. Обычно мы открываем одну ветку за раз, хотя иногда у нас было больше.
Ryan Taylor 24.07.2009 16:01:32
Я считаю, что наши проблемы возникли из нескольких вопросов, которые все были решены. 1. Наши клиенты Subversion не были в той же версии. Некоторые были слиты неосведомленными и сделали слияния неосведомленными комментариями. 2. Мы выполняли частичные слияния (с другим клиентом Subversion) 3. Наш сервер Subversion был 1.5.0. Это было только что обновлено до 1.6.3 на прошлой неделе. У нас уже был лучший опыт слияния, чем с предыдущей версией. Я думаю, что все это способствовало ошибкам, которые мы имели выше.
Ryan Taylor 24.07.2009 16:04:16

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

0
3.08.2009 14:53:33

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

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

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

1
23.05.2017 12:24:26

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

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

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

4
4.01.2010 04:33:20

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

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

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

19
12.05.2010 19:21:37
У меня тоже была эта проблема - ваше решение исправило ее для меня. :)
Jimmy Cuadra 1.06.2010 21:04:05
Отличное простое решение! просто верните файлы и подтвердите изменения снова. Brilliant.
jasop 19.09.2012 10:41:18

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

svn update
svn resolved <the directory in conflict>
svn commit
26
6.08.2010 12:42:25
Для этого в IntelliJ вам понадобится плагин «Поддержка командной строки». Чтобы получить его, откройте Файл> Настройки (или Ctrl + Alt + S)> Плагины. Нажмите кнопку «Обзор репозиториев». Найдите плагин «Поддержка командной строки». Нажмите на кнопку «Установить» на нем. Перезапустите IntelliJ. Теперь, когда все настроено, вы можете просто нажать Инструменты> Выполнить команду (или нажмите Ctrl + Shift + X) и запустить ваши команды в IntelliJ.
Jeremy Moritz 11.10.2017 14:41:32

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

0
28.10.2010 13:30:41

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

1
14.12.2010 12:29:02

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

3
2.10.2012 15:51:30

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

0
10.04.2013 16:54:44

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

======= код объединен с ревизией репозитория "

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

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

0
23.06.2014 07:50:02

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

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

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

5
3.09.2014 09:02:04

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

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

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

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

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

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

Мой последний совет ...

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



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

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



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

1
2.10.2016 18:57:29

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

svn update

а потом я совершаю и бум это сработало!

2
8.02.2017 20:23:41

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

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

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

  1. SVN обновление
  2. SVN решен
  3. SVN совершить
0
19.03.2018 09:11:29