Хороший способ ограничить стоимость слияния для ветвей функций в SVN

Question

Кто-нибудь может порекомендовать шаблоны рабочих процессов / использования, которые снижают стоимость / сложность слияний при использовании Agile с SVN?

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

Недавно мы перешли от нестабильной модели магистрали с ответвлениями обслуживания и стабилизации от магистрали к стабильной магистрали с функциональными ветвями. У нас есть магистраль со старыми ветвями обслуживания для поддержки и новые ветки команды с функциональными ветвями из них.

Команда разрабатывает функции и отправляет их в ветку команды, а затем в ствол. Иногда функции также объединяются между ветвями объектов. Мы сталкиваемся с некоторыми проблемами, связанными с конфликтами деревьев (особенно когда набор изменений помещается как в транк, так и в другую ветвь функций).

Когда нам нужно перенести изменения в ветки поддержки или перенести изменения из них в магистраль, это очень сложно. Багажник и техническое обслуживание немного сместились.

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

Кто-нибудь может порекомендовать хорошие статьи, стратегии или инструменты?

Answer 1

Я бы порекомендовал:

• Синхронизируйте ветвь функции с внешней линией.Сделайте это регулярным заданием, это не займет много времени, если вы будете делать это каждые пару дней.Когда вы будете готовы отбросить работу в сундук, убедитесь, что она получила здоровую дозу QA, и используйте слияние reintegrate .Реинтеграция опрашивает свойство svn: mergeinfo для файлов и папок, чтобы гарантировать, что изменения, синхронизированные из внешней линии в вашу функциональную ветвь, не синхронизируются обратно ('циклические' слияния).

• Убедитесь, что вытолько ветви от ствола, не «каскадные» ветви от других ветвей.У нас были случаи, когда свойство COPY-TO в переименованном файле не отслеживалось при объединении файла.Это может привести к неправильному удалению SVN, и эта проблема усугубляется, если у вас есть каскадные ветви.

• Раньше у нас были серьезные проблемы с svn: mergeinfo: были ошибки всистема, когда она была впервые представлена ​​и в конечном итоге поместила mergeinfo практически на каждый файл и папку.Это принесло нам больше вреда, чем пользы при слиянии, просто запуталось, поэтому мы решили очистить mergeinfo для каждого файла и папки, кроме корневой папки нашего репозитория.Это тогда действует как хорошее резюме деятельности филиала.Если вы сделаете это, вы не получите всех возможностей SVN-отслеживания перемещений папок / файлов, но у нас было так много проблем, что в итоге мы стали быстрее разрешать конфликты деревьев при необходимости. Примечание: эта политика является спорной.Я не рекомендую делать это, если вам действительно не нужно, но это хорошо сработало для нас.

• Говоря о перемещениях папок / файлов, не сходите с ума, реструктурируя свою кодовую базу,Перемещайте файлы и папки только в том случае, если это действительно необходимо и если вы действительно сообщаете об изменениях своей команде.

• То же самое касается переименования, не переименовывайте вещи без уважительной причины.Имена файлов в хранилище чувствительны к регистру, но файлы Windows не чувствительны к регистру.Поэтому, если вы измените файл с «foo.txt» на «Foo.txt» и затем вернетесь к «foo.txt», во время слияния SVN попытается удалить, добавить, а затем повторно добавить файл.Он думает, что это по-другому, но файловая система будет жаловаться, и она спасет от слияния.Это очень неприятные случаи.

• Следуя комментариям Сандера Рийкена: наряду с проверкой отсутствия локальных изменений также рекомендуется регулярно удалять любые непредвиденные файлы.Если у вас есть плавающий файл, в котором попытка слияния для записи поверх SVN может запутаться.Для таких случаев у нас есть несколько сценариев поддержки Ruby.

• Обратите внимание на конфликты деревьев.Их легко решить, если слить в небольших дозах.Вам просто нужно посмотреть историю изменений файла в кодовой строке, из которой вы объединяете, и повторно применить их вручную к месту назначения.Это наихудший случай, но если у вас есть правильное лицо, ответственное за слияние, например, ведущий проекта с пониманием работы, тогда они могут быть решены относительно быстро.

• Наконец, убедитесь, что ваши клиенты SVN обновлены.

• О, да, и хороший инструмент слияния может сделать весь процесс намного менее болезненным.Я использую Araxis, но я слышал, что инструмент слияния в SmartSVN тоже хорош.

Answer 2

В зависимости от того, насколько автономны определенные функции, вы можете рассмотреть возможность создания модулей функций и включить их (возможно, закрепление определенной версии) в svn:externals.Это зависит от того, подходит ли кодовая база / проект для такого рода модульности.

Answer 3

SVN на самом деле не был разработан для рабочего процесса ветки функций, как вы, вероятно, уже можете сказать.Если вы собираетесь приблизиться к этому, попробуйте Git или другую DVCS, и все будет намного лучше для вас.Это стоит вложений, чтобы переключиться.

Answer 4

Несколько вещей, которые я могу придумать, помогают уменьшить возможные конфликты:

• Убедитесь, что ваша рабочая копия имеет одну ревизию, запустив svn up в корне рабочей копии.
• Убедитесь, что у вас нет локальных изменений
• Убедитесь, что нет дочерних элементов переключения (это происходит, когда вы переключаете каталог внутри wc вместо самого wc)
• Убедитесь, что рабочая копия извлечена с глубиной = бесконечность, т.е. без разреженной рабочей копии