Расписал немного про HG

Свободное общение

Модераторы: Xpycm, Koduc

Расписал немного про HG

Сообщение Koduc » 28 дек 2011, 12:09

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

Если остаются еще непонятные моменты - спрашиваем, постараюсь ответить.
-- Меньше знаешь - крепче спишь --
Аватара пользователя
Koduc
Ведущий разработчик
Ведущий разработчик
 
Сообщения: 902
Зарегистрирован: 28 дек 2011, 09:11
Очки репутации: 20

Re: Расписал немного про HG

Сообщение Koduc » 28 дек 2011, 18:26

Временно снял статью с публикации - нашел небольшие неточности. Выложу снова как поправлю.
-- Меньше знаешь - крепче спишь --
Аватара пользователя
Koduc
Ведущий разработчик
Ведущий разработчик
 
Сообщения: 902
Зарегистрирован: 28 дек 2011, 09:11
Очки репутации: 20

Re: Расписал немного про HG

Сообщение Koduc » 28 дек 2011, 21:16

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

Рекомендую к изучению!
Я понимаю, что рассмотрел самые простые и примитивные варианты, очень во многих местах можно написать множество оговорок.
Но именно к такому простому workflow я хочу привести разработку - не стоит всё усложнять.
-- Меньше знаешь - крепче спишь --
Аватара пользователя
Koduc
Ведущий разработчик
Ведущий разработчик
 
Сообщения: 902
Зарегистрирован: 28 дек 2011, 09:11
Очки репутации: 20

Re: Расписал немного про HG

Сообщение Xpycm » 30 дек 2011, 11:10

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

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

Сам так делал при написании дипломной работы несколько лет назад, когда не умел пользоваться тем же SVN
Dropbox
Open Real Estate CMS: FAQ | FAQ 2 | FAQ 3
Изображение
Xpycm
Разработчик
Разработчик
 
Сообщения: 1592
Зарегистрирован: 30 дек 2011, 11:06
Откуда: Йошкар-Ола
Очки репутации: 50

Re: Расписал немного про HG

Сообщение ANest » 06 фев 2012, 16:36

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

Re: Расписал немного про HG

Сообщение Koduc » 07 фев 2012, 09:53

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

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

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

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

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

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

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

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

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

Собственно, мы пример того, как модульность и рабочий процесс обеспечивают совершенно безпроблемную работу. Никто никому не мешает, не злится "опять он всё сломал" - слияние почти всегда проходит без конфликтов в автоматическом режиме, а высокая скорость разработки на Yii позволяет каждый день коммитить работающий код.
-- Меньше знаешь - крепче спишь --
Аватара пользователя
Koduc
Ведущий разработчик
Ведущий разработчик
 
Сообщения: 902
Зарегистрирован: 28 дек 2011, 09:11
Очки репутации: 20

Re: Расписал немного про HG

Сообщение ANest » 13 фев 2012, 08:29

Ясно. Спасибо за объяснения.
З.Ы. У нас, к сожалению, структура несколько иная. Язык разработки С++. В одном исполняемом модуле присутствует код 2-3-х разработчиков. Наверное, это не есть хорошо, но пока то, что есть. :-(
ANest
Незнакомец
 
Сообщения: 2
Зарегистрирован: 06 фев 2012, 16:33
Очки репутации: 0

Re: Расписал немного про HG

Сообщение Koduc » 15 фев 2012, 09:20

Всегда есть возможность изменить рабочий процесс "снизу". На C/C++ тоже ведь можно сделать разделение - библиотеки, например (как вариант, COM-компоненты). Описывается только API - что должно быть на входе, что на выходе. И так несколько библиотек радаются разным программерам. Ведущий прогаммер собирает все библиотеки в единое приложение. Благодаря тому, что API описывается заранее при постановке задачи - сразу можно писать документацию и получится в добавок документированные функции API модулей.
-- Меньше знаешь - крепче спишь --
Аватара пользователя
Koduc
Ведущий разработчик
Ведущий разработчик
 
Сообщения: 902
Зарегистрирован: 28 дек 2011, 09:11
Очки репутации: 20

Re: Расписал немного про HG

Сообщение Aibolit » 03 июл 2012, 17:24

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

Re: Расписал немного про HG

Сообщение Koduc » 04 июл 2012, 09:31

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


Нет, такое расширение не использовали.
Зачем нам в девелоперском коде номера ревизий, даты и прочее?
Собираем архив продукта по сути один раз в пару месяцев, там просто find & replace через скрипт меняет что надо, чистит ненужное и пакует в архив готовый для скачивания.
Из-за столь нечастой процедуры не вижу смысла в такого рода расширении.
Такое расширение, можеть быть, будет полезно при Agile разработке, где новые версии рабочие должны быть каждую неделю (ну или сколько там итерация выбрана по длительности).
-- Меньше знаешь - крепче спишь --
Аватара пользователя
Koduc
Ведущий разработчик
Ведущий разработчик
 
Сообщения: 902
Зарегистрирован: 28 дек 2011, 09:11
Очки репутации: 20

След.

Вернуться в Курилка

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 64

cron