Создание нескольких голов в удаленном хранилище

Question

Мы хотим перевести нашу команду (~ 10 разработчиков) из SVN в Mercurial. Мы пытаемся выяснить, как управлять нашим рабочим процессом. В частности, мы пытаемся выяснить, является ли создание удаленных головок правильным решением.

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

То, как мы в настоящее время обрабатываем это в SVN, это ветви. У Team1 есть ветка для Feature1, такая же сделка для других команд. Когда Team1 заканчивает свое изменение, оно объединяется в транк и развертывается. Другие команды следуют за набором, когда их проект завершен, слияние конечно.

Итак, моя первоначальная мысль - использовать именованные ветви для этих ситуаций. Team1 делает ветку Feature1 из ветви по умолчанию в Hg. Теперь вот вопрос. Если команда НАЖМИТ эту ветвь в текущем / наполовину состоянии в хранилище. Это создаст вторую голову в репо ядра.

Моя первоначальная реакция была "НЕТ!" как это кажется плохой идеей. Обработка нескольких головок в нашем хранилище звучит просто ужасно, но есть некоторые преимущества ...

Во-первых, команды хотят настроить Непрерывную Интеграцию, чтобы построить эту ветку в течение их цикла разработки (продолжительностью несколько месяцев). Это будет работать только в том случае, если CI сможет извлечь эту ветку из репо. Это то, что мы делаем сейчас с SVN, копируем сборку CI и меняем ветку. Легко.

Во-вторых, любому члену команды легче запрыгнуть на ветку и начать работать. Без подталкивания к репо ядра они должны были бы получить толчок от разработчика в этой команде с информацией о ревизиях. Также возможно потерять локальные коммиты из-за аппаратного сбоя. Шансы значительно возрастают, если это ветвь одного разработчика, который придерживался подхода «не нажимай до конца».

И, наконец, просто для удобства использования. Разработчики могут легко зафиксировать и нажать на свою ветку в любое время без последствий (как они делают сегодня, в своих ветках SVN).

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

Для исправления ошибок нам нравится общий рабочий процесс Mercurial, анонимных веток, которые состоят только из 1-2 коммитов. Простота отлично подходит для этих случаев.

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

Answer 1

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

• Как вы показали, один репозиторий, с одной веткой для общего кода и одной веткой для каждого проекта. Когда сами проекты создаются путем разветвления базы общего кода, необходимо соблюдать осторожность при слиянии с общим (выбор вишни). Когда внутри каждой ветки проекта обновления общей ветки генерируются как прямые предки общей ветки и объединяются с веткой проекта, велика вероятность, что они также могут быть объединены в общую. Но если изменения общего будут разработаны в верхней части ветки проекта, объединение обратно потребует выбора вишни. У меня нет опыта такой настройки, но я боюсь, что слияния могут стать проблематичными.
• один репозиторий для общего кода и один репозиторий для каждого проекта, связанных символическими ссылками или в виде подпункта. Здесь необходимо соблюдать осторожность, чтобы не наступать друг другу на корма. По моему опыту, такое использование потенциально может вырасти в очень большую PITA. OTOH, кажется, у вас уже есть эта настройка, и ваши коллеги разработчики могут работать с ней.
• один репозиторий для общего ресурса и один для каждого проекта, а код из общего ресурса используется в качестве внутренних выпусков. Я бы пошел на эту настройку, когда в базе разделяемого кода нет больших регулярных изменений.

Все эти ситуации также могут быть объединены с ветвями настройки для каждого проекта в общей части. Но я бы постарался свести к минимуму количество активных в настоящее время веток, поскольку каждая новая ветвь требует дополнительного ухода за слияниями.

Извините, что не даю конкретного ответа, но "Правильная вещь" (ТМ) во многом зависит от местных деталей.

Answer 2

Вы определенно думаете об этом праве, и, похоже, вы идете по правильному пути. Я ветвь как человек-клон, но названные ветки прошли долгий путь.

Наличие репозитория central-ish, куда помещаются все именованные ветви, удобно для управления и резервного копирования. Команды, работающие только на ветке X, могут легко создать свое собственное репо только для ветви X, выполнив hg clone -r X central-ish repo.

Лучшее, что вы можете сделать, чтобы помочь командам, - это позволить им самим делать клоны где-нибудь за экземпляром hgwebdir.cgi (как, вероятно, будет ваш репо с центральным тиражом). Вы найдете не только команды, но подгруппы и пары команд создадут свои собственные репозитории для мини-усилий, о которых вы никогда не узнаете. Они поместят их в именованные ветви, которые имеют для них смысл, и при необходимости вернутся в центральную.