Как управлять одновременным развитием с Mercurial?
-
02-10-2019 - |
Вопрос
Это лучшая практика вопрос, и я ожидаю, что ответ будет «это зависит». Я просто надеюсь узнать больше реальных сценариев и рабочих процессов.
Прежде всего, я говорю о разных изменениях для одного и того же проекта, поэтому нет Subrepo, пожалуйста.
Допустим, у вас есть ваша база кода в репозитории HG. Вы начинаете работать над сложным новым функциями A, то усложненной ошибкой B сообщается вашим доверенным тестером (у вас есть тестеры, верно?).
Это тривиально, если (исправление для) B зависит от A. Вы SimLPly CI A затем CI B.
Мой вопрос - это то, что делать, когда они независимы (или, по крайней мере, кажется сейчас).
Я могу думать о следующих способах:
- Используйте отдельный клон для B.
- Используйте анонимные или названные ветви или закладки, в том же репозитории.
- Используйте MQ (с Batch B на вершине A).
- Используйте разветвленный MQ (я объясню позже).
- Используйте несколько MQ (с 1,6)
1 и 2 покрыты Отличный блог @steve Losh связан с Слегка связанный вопрос.
Одно огромное преимущество 1 над другим вариантом состоит в том, что оно не требует никакой восстановления, когда вы переходите с работы над одним другим, потому что файлы физически разделены и независимы. Таким образом, это действительно единственный выбор, если, например, A и / или B касается файла заголовка, который определяет логию TRI-состояния и включается в размере тысяч файлов C (не говорите мне, что вы не видели такого устаревшего кода основание).
3, вероятно, самый простой (с точки зрения настройки и накладных расходов), и вы можете перевернуть порядок A и B, если B - это небольшое и / или срочное исправление. Однако это может быть сложно, если A и B касается одного и того же файла (ы). Легко исправить патч, которые не удалось применить, если изменения A и B являются ортогональными в одном и тем же файлам (ов), но концептуально это все еще немного рискованно.
4 Может сделать вас головокружение, но это самый мощный и гибкий и масштабируемый путь. Я по умолчанию hg qinit
с участием -c
Поскольку я хочу пометить патчи для работы в процессе прогресса и нажать / вытащить их, но он делает концептуальный скачок, чтобы понять, что вы можете отразить в MQ REPO. Вот шаги (MQ = Hg --mq):
hg qnew bugA
; внести изменения для A;hg qref
mq branch branchA; hg qci
hg qpop; mq up -rtip^
hg qnew bugB
; внести изменения для b;hg qref
mq branch branchB; hg qci
- Работать снова:
hg qpop; mq up branchA; hg qpush
Кажется сумасшедшим, чтобы занять так много шагов, и когда вам нужно переключать работу, вы должны hg qci; hg qpop; mq up <branch>; hg qpush
. Отказ Но рассмотрим это: у вас есть несколько именованных филиалов выпуска в одном репозитории, и вам нужно работать над несколькими проектами и исправлениями ошибок в то же время для всех них (вам лучше получить гарантированный бонус для такого рода работы). Вы бы потеряли очень скоро с другими подходами.
Теперь мои любители HG HG, есть другие / лучшие альтернативы?
(ОБНОВИТЬ) qqueue
почти делает # 4 устаревшим. Смотрите элегантное описание Стива Лоша здесь.
Решение 2
Похоже, что нет более или лучших вариантов, чем у тех, которые я перечислил в вопрос. Так что здесь они снова.
- Используйте один клон на проект.
- Плюсы: Общее разделение, тем самым не перестраивается при коммутации проектов.
- Минусы: Написания необходимо переключаться между двумя клонами.
- Используйте анонимные или названные ветви или закладки, в том же репозитории.
- Плюсы: стандартная практика HG (или любых DVC); чистый и очистить.
- Минусы: должны совершать до переключения и восстановления после.
- Используйте MQ с одним патч (или несколько последовательных патчей) на проект.
- Плюсы: простые и легко.
- Минусы: обязан
qrefresh
до переключения и восстановления после; хитрый и рискованный, если проекты не являются ортогональными.
- Используйте одну ветвь MQ (или
qqueue
в 1.6+) на проект.- Плюсы: ультра гибкий и масштабируемый (для количества одновременных проектов)
- Минусы: обязан
qrefresh
а такжеqcommit
до переключения и восстановления после; чувствует себя сложным.
Как всегда, нет серебряной пули, так что выберите и выберите одно право на работу.
(Обновление) Для всех, кто влюблен в MQ, используя MQ сверху обычных ветвей (# 2 + # 3), вероятно, является наиболее распространенной и предпочтительной практикой.
Если у вас есть два одновременного проекта с базовым уровнем на двух ветвях (например, следующий выпуск и текущий выпуск), он тривиален для переключения между ними так:
hg qnew; {coding}; hg qrefresh; {repeat}
hg qfinish -a
hg update -r <branch/bookmark/rev>
hg qimport -r <rev>; {repeat}
Для последнего шага, qimport
следует добавить А. -a
Возможность импортировать линию изменений сразу. надеюсь Мейстер Дейслер Уведомления об этом :)
Другие советы
Я всегда буду использовать именованные филиалы, потому что это позволяет Mercurial сделать свою работу: чтобы сохранить свою историю проекта и помнить, почему вы сделали, какие изменения в каком порядке к вашему исходному коду. Будь то один клон или два сидения на вашем диске, как правило, легко, учитывая мой рабочий стиль, по крайней мере:
Отсутствует ли ваш проект процесса сборки, чтобы вы могли проверить и запускать вещи прямо из исходного кода? Тогда я буду соблазн иметь только один клон, и
hg up
Взад и вперед, когда мне нужно работать над другой веткой.Но если у вас есть сборка, Virtualenv или другая структура, которая создается, и это может расходиться между двумя ветвями, затем делает
hg up
Затем в ожидании процесса сборки, чтобы повторно запустить, может быть большим болью, особенно если привлечены такие вещи, как настройки базы данных образца. В этом случае я определенно использовал два клона, один сидя на кончике багажника, и один сидит на кончике ветви экстренной функции.
Таким образом, вопрос в том случае, если вам говорят прекратить работу над функциями A и начать независимую функцию B, какие альтернативные варианты существуют, для: Как управлять одновременным развитием с Mercurial?
Давайте посмотрим на проблему с удаленным параллелизмом, так же, как вы пишете резьбовой код - определите простой рабочий поток для решения любой проблемы, придаваемой вам, и примените ее к каждой проблеме. Mercurial присоединится к работе, как только это сделано. Таким образом, Programmer A будет работать над функцией A. Programmer B будет работать над функцией B. Оба только что случится. (Если бы у нас были многоядерные мозги :)
Я всегда буду использовать именованные филиалы, потому что это позволяет Mercurial сделать свою работу: чтобы сохранить свою историю проекта и помнить, почему вы сделали, какие изменения в каком порядке к вашему исходному коду.
Я согласен с чувствами Брэндона, но мне интересно, если он упустил из виду, что функция A не была проверена? В худшем случае код компилирует и пропускает модульные тесты, Но некоторые методы реализуют предыдущие требования, а некоторые методы реализуют новые. Diff против предыдущей регистрации заезда - инструмент, который я бы использовал, чтобы помочь мне вернуться на трек с функцией A.
Ваш код для функции A в точке, когда вы обычно проверяете это? Переключение от функции A для работы над функцией B - не причина, чтобы совершить код до головы или в ветку. Проверьте только код, который компилирует и передает ваши тесты. Моя причина в том, что если Programmer C должен начать функцию C, новая проверка этой ветки больше не является лучшим местом для начала. Хранение ваших ветвей головы здоровы, означает, что вы можете быстро ответить, с более надежными исправлениями ошибок.
Цель состоит в том, чтобы пройти свой (проверенный и проверенный) код, поэтому вы хотите, чтобы весь ваш код в конечном итоге объединился в голову (ваша разработка и устаревшие ветви). Моя точка зрения, по-видимому, я видел разветвление, используемую неэффективно: код становится устаревшим, а затем не используется, слияние становится сложнее, чем исходная проблема.
Только ваш вариант 1 имеет смысл для меня. В основном:
- Вы должны подумать, что ваш код работает, прежде чем кто-то другой видит его.
- Подготовьте голову над веткой.
- Филиал и регистрация, если кто-то другой поднимает проблему.
- Ветвь Если ваша автоматизированная система или тестеры нужны только ваш код.
- Ветвь Если вы являетесь частью команды, работая над проблемой. Считайте это головой, см. 1-4.
За исключением файлов конфигурации, процессы сборки должны быть оформлением заказа и одной командой сборки. Не должно быть сложнее переключаться между клонами, чем для нового программиста, чтобы присоединиться к проекту. (Я признаю, что мой проект нужна здесь некоторая работа.)