Форум Monoray.ru

У всех начинающих работать с HG возникают примерно одинаковые проблемы. Постарался расписать рабочий процесс в статье: http://monoray.ru/15-mercurial-commiting-merging

Если остаются еще непонятные моменты - спрашиваем, постараюсь ответить.

Временно снял статью с публикации - нашел небольшие неточности. Выложу снова как поправлю.

Вернул статью, также сделал еще одну: http://monoray.ru/17-mercurial-merging-named-branches

Рекомендую к изучению!
Я понимаю, что рассмотрел самые простые и примитивные варианты, очень во многих местах можно написать множество оговорок.
Но именно к такому простому workflow я хочу привести разработку - не стоит всё усложнять.

В комментарий к статье:

Даже при разработке одному система контроля версий облегчает жизнь - отпадает необходимость каждодневного копирования рабочей копии по папкам с названиями что-то вроде: "2011_12_20 (всё работает)" или "2011_12_21 (добавил редактирование пользователей)" и т.п

Сам так делал при написании дипломной работы несколько лет назад, когда не умел пользоваться тем же SVN

Здравствуйте.
У меня несколько вопросов.
1. У каждого продукта есть версии: 1.0, 1.6, 2.0 и т.д. Каким образом организована идентификация версий вашего продукта в ветке release? Используете ли вы tag'и?
2. Существует несколько разработчиков и определенный ряд задач, которые они решают. Когда разработчик реализовал какую-то задачу, протестировал, посчитал, что пришло время выложить код в основной репозиторий и сделал это в ветку default. Может случитьтся так, что после данной операции рабочая версия проекта вцелом перестанет собираться/работать. Что делать в этом случае? Другие разработчики, вытянув (pull) изменения в свои локальные репозитории, могут попасть в неприятную ситуацию. Я прав?
3. Не пробовали создавать именнованные ветви для реализации какого-то функционала или исправления ошибки, ответвляясь от основной ветви разработки default? Затем, когда менеджер проекта утвердит реализации, слить с той же веткой default. А в это время разработчики спокойно могут тянуть изменения только ветки default, которая более-менее стабильна и находится под контролем менеджера проектов?

Здравсвуйте!

ANest писал(а):У каждого продукта есть версии: 1.0, 1.6, 2.0 и т.д. Каким образом организована идентификация версий вашего продукта в ветке release? Используете ли вы tag'и?

От тэгов отказались, неудобно оказалось.
Было как: сливаются все изменения в ветку release, тестируются. Вроде бы как работает. Навешиваем тэг, запускаем срипт, который собирает архив. Частенько бывает - что в базе какие-то изменения не те перетянулись или еще что-то по-мелочи. То есть архив есть, продукт выпущен, но скачиваний еще очень мало. Вместо того, чтобы делать еще одну релизную версию - быстро правим текущую версию, но опа - у нас уже навешан тэг, надо вешать снова..

Поэтому делается просто. Сливаюся все изменения в ветку release. Запускаю скрипт, который проставляет во все файлы текущую версию продукта (указываю руками) и собирает архив для скачивания. Если что-то надо поправить - вносим правки в ветку и запускаем скрипт с той же версией в параметрах, всё пересобирается.

Проблемы идентификации не возникает - так как от выпуска до выпуска никто ветку не трогает. Что происходит выпуск - пишу в комментариях к коммиту.

ANest писал(а):Что делать в этом случае? Другие разработчики, вытянув (pull) изменения в свои локальные репозитории, могут попасть в неприятную ситуацию. Я прав?

Глобально проект не ломался ни разу:)
Структура проекта полностью модульная, над одним модулем работает один человек. Чтобы всё сломать - очень постараться надо.

Модули бывает ломаются из-за того, что забыли какие-то изменения в базу положить. Решается в течении пары минут, бывает такое 3-4 раза в месяц. Не работает в данном случае, напоминаю, только один из модулей. Все прекрасно могут работать дальше над своими модулями не обращая внимания на ошибку.

ANest писал(а):Затем, когда менеджер проекта утвердит реализации, слить с той же веткой default

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

Вообще, пункты 2-3 были бы актуальны, если бы иначе была поставлена работа, продукт был бы не модульный или в качестве репозитория был svn, где слияение и переключение между ветками - задача та еще.

Собственно, мы пример того, как модульность и рабочий процесс обеспечивают совершенно безпроблемную работу. Никто никому не мешает, не злится "опять он всё сломал" - слияние почти всегда проходит без конфликтов в автоматическом режиме, а высокая скорость разработки на Yii позволяет каждый день коммитить работающий код.

Ясно. Спасибо за объяснения.
З.Ы. У нас, к сожалению, структура несколько иная. Язык разработки С++. В одном исполняемом модуле присутствует код 2-3-х разработчиков. Наверное, это не есть хорошо, но пока то, что есть. :-(

Всегда есть возможность изменить рабочий процесс "снизу". На C/C++ тоже ведь можно сделать разделение - библиотеки, например (как вариант, COM-компоненты). Описывается только API - что должно быть на входе, что на выходе. И так несколько библиотек радаются разным программерам. Ведущий прогаммер собирает все библиотеки в единое приложение. Благодаря тому, что API описывается заранее при постановке задачи - сразу можно писать документацию и получится в добавок документированные функции API модулей.

Спасибо вам за статьи.
Пытаюсь оптимизировать рабочий процесс и, прочитав ваши подсказки, до конца не понял пробовали ли вы использовать keyword-расширение mercurial?
Вроде не нужен никакой робот и ключевые слова сами прописываются в изменившиеся файлы. Там могут быть как переменные (дата, время, пользователь), так и константы типа номера версии и чего угодно.
Ведь если закоммитить с ошибкой и затем изменить несколько файлов, то достаточно изменить номер версии в hgrc (например увеличить минорную часть) и после коммита новая версия будет стоять в каждом изменившемся файле.
Может неудобство в том, что не у всех файлов одинаковая версия? Честно говоря, не занимался поддержкой сложных проектов, но это может быть даже преимуществом, т.к. если файл не менялся, то пусть остается со своей версией. Единую версию проекта можно как-раз ставить через тег.

Aibolit писал(а):Пытаюсь оптимизировать рабочий процесс и, прочитав ваши подсказки, до конца не понял пробовали ли вы использовать keyword-расширение mercurial?

Нет, такое расширение не использовали.
Зачем нам в девелоперском коде номера ревизий, даты и прочее?
Собираем архив продукта по сути один раз в пару месяцев, там просто find & replace через скрипт меняет что надо, чистит ненужное и пакует в архив готовый для скачивания.
Из-за столь нечастой процедуры не вижу смысла в такого рода расширении.
Такое расширение, можеть быть, будет полезно при Agile разработке, где новые версии рабочие должны быть каждую неделю (ну или сколько там итерация выбрана по длительности).