В моем офисе мы переходим от Visual Source Safe (6.0!) К Mercurial, и я пытаюсь понять лучший «меркуриальный» способ обработки нашей ситуации. В настоящее время в любом репозитории проекта мы поддерживаем несколько его версий: например, для Project A, у нас есть VSS Repo для ProjA-Dev, ProjA-Rel1 и ProjA-Rel2 (dev-репо и один для каждого из двух последних релизов).Лучшие практики в Mercurial для поддержки ветвей Dev/Release?
В настоящее время (почти) все новые работы выполняются в dev-репо, а затем изменения, которые считаются необходимыми для возврата в Rel1 или Rel2, выполняются вручную (файлы, извлеченные из VSS, к их собственный рабочий каталог, а затем с помощью некоторого инструмента сравнения только копирование соответствующих изменений). В какой-то момент считается, что будет выпущен новый релиз, поэтому dev-репо будет клонировано и будет Proj * -Rev1, а предыдущий Proj * -Rev1 станет Proj * -Rev2, а Proj * -Dev просто продолжается как будто ничего не произошло. Мне кажется, что должен быть лучший способ сделать это в гораздо более современном инструменте, таком как Mercurial.
Моя нынешняя мысль состоит в том, что каждый проект должен иметь свой собственный репозиторий, а различия Dev/Rel1/Rel2 лучше всего обрабатывать разными именованными ветвями. Однако то, что я не могу понять/видеть/обернуть головой, - это то, как выполнить наш текущий рабочий процесс в такой среде. Если мы будем следовать нашему текущему рабочему процессу, то работа продолжит работу в dev-ветке, и определенные изменения (не все!) Будут отброшены назад в ветви Rel. Я знаю, что это может быть достигнуто с помощью функции трансплантации/трансплантата Mercurial, которая, похоже, не очень хорошо поддерживается в TortoiseHg. И, что более важно, прошлые ответы, похоже, предполагают, что наилучшим решением для этого является не позволить вещам попасть в такое состояние, чтобы начать с 1.
Вопрос в том, что является лучшим способом избежать такого состояния, учитывая текущий рабочий процесс? Я прочитал множество руководств о Mercurial и ветвлении (включая многие, многие ответы, найденные здесь), но не видел четкого ответа на этот вопрос.
Одна концепция, которая обрабатывает это рекламные группы, в соответствии с которыми цикл dev/test/rel можно рассматривать как измерение качества (того же «листа» того же кода), которое является ортогональным к стандартным «функциональным наборам» типа ветвления , Я не знаком с Mercurial, поэтому не могу помочь напрямую. например http://www.ericsink.com/scm/scm_branches.html – StuartLC
Почему бы не выпустить DEV? Я не пытаюсь быть тупым, просто понимаю рассуждения. Если это потому, что функция не закончена, то, возможно, эта работа должна была быть выполнена на собственной «ветке» (не обязательно «именованной ветке»). Я думаю, что ключевым моментом является то, что ветви функций обычно происходят в DVCS, поэтому, если кто-то намеренно не подталкивает незавершенную работу к DEV, вы не должны иметь слишком много вещей в DEV, которые не перемещаются в RELEASE. –