Как определить, если svn: mergeinfo поврежден и как я могу это исправить?

Question

Я подозреваю, что у меня испорченная информация mergeinfo, но я не уверен. Кто-нибудь знает, как я могу определить и какие ресурсы существуют для решения проблем?

Вот проблема. Моя команда недавно перешла на гибкую и использует ветки функций (на самом деле ветки истории), где разные команды работают одновременно над одними и теми же источниками. По мере того как история достигает высокой степени готовности, команда сливается в ствол. Слияния занимают дни или недели из-за отсутствующих изменений, неожиданных изменений и конфликтов. Мы говорим о командах из 5-10 человек, и усилие / отток кажется слишком высоким.

Люди используют этот шаблон слияния a) PULL - объединить магистраль с ветвью, разрешить, проверить, зафиксировать б) PUSH - объединить ветвь с магистралью, разрешить, проверить, зафиксировать c) Воссоздать ветку (или обычно создать новую ветку истории и отбросить старую, так как это сделано)

К концу этого ветвь и ствол должны быть выровнены.

Проблемы, с которыми мы сталкиваемся:

1. Изменения, о которых не сообщалось во время слияния между ветвями, обнаруживаются в последующих ветвях к стволу
2. конфликты в свойствах svn: mergeinfo во время слияния
3. файл отсутствует, но локальное редактирование нового файла добавлено в ветку и передано в транк
4. Входящий + локальное удаление (файл, удаленный на соединительной линии и ветви, отображается как конфликт)

(1) Не должно происходить. Вытягивание от ветви к стволу должно синхронизировать эти два изменения для всех стволов. Изменения в слиянии между ветвями и ветвями - это изменения, произошедшие в стволе. Таким образом, при первом слиянии они должны были распространиться на ветку, но не сделали этого. Это указывает на повреждение данных mergeinfo, которое «скрыло бы» изменения в магистрали.

(2) Не должно происходить. SVN должен управлять изменениями в отслеживании слияний. Это также указывает на повреждение в данных mergeinfo

(3) Не должно происходить. Это случай добавления нового файла в ветку. Он должен отображаться как новый файл, добавленный в транк. Это также указывает на повреждение данных слияния.

(4) Я считаю, что это ошибка SVN, и мы не можем это исправить. Тем не менее, если бы это была наша единственная проблема, я был бы счастлив

В настоящее время мы находимся на сервере svn 1.5.x с клиентами, использующими svn 1.6.x и svn + ssh для подключения. Мы планируем перейти на последнюю и лучшую версию SVN, поскольку некоторые исправления могут повлиять на наши проблемы.

Тем не менее, похоже, что наши данные mergeinfo неверны.

• Слияния, которые не сообщают обо всех изменениях
• Конфликты при слиянии свойств mergeinfo

Какие-нибудь хорошие места для меня, чтобы начать искать?

Answer 1

У нас были похожие проблемы из-за сходных обстоятельств, и мы в основном решили их.

Главный из них:

Если вы объединяетесь в свою ветку из ствола после создания ветки, вам нужно пометить ствол с помощью фиксации ветки (используя svn merge --record-only), в противном случае, когда вы пытаетесь реинтегрировать обратно в ствол, он пытается объединиться фиксация транка на ветке обратно в транк.

Это, очевидно, в конечном итоге отменяет изменения в стволе, сделанные после более поздней фиксации trunk-> branch, имеет тенденцию вызывать массовые конфликты (особенно конфликты деревьев, если вы создали новый файл или каталог в trunk) и т. Д.

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

• ветка b от ствола
• фиксирует транк и ветку
• реинтегрировать транк в ветвь и фиксировать (разрешать конфликты, но без изменений, даже компилировать)
• немедленно выполнить svn-слияние --record-only ревизии фиксации магистрали к ветви
• исправьте любые другие проблемы с веткой и продолжайте разработку
• реинтегрировать из ветви в ствол, когда закончите.

Я нашел: http://www.collab.net/community/subversion/articles/merge-info.html полезно, когда мы понимаем, что мы делаем неправильно.

Answer 2

Я провел несколько экспериментов с ветвлением / слиянием SVN и обнаружил, что в некоторых ситуациях слияние просто не работает - например, изменения из транка перезаписываются.Так что, если вы продолжите использовать SVN для ветвей функций, вы будете испытывать боль.

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