Доброго времени суток! Настроил связку Mercurila + NetBeans + Apache 2. Всё работает просто замечательно! После коммита - меркурий (*Mercurial, HG) сливает файлы из репозитория в определённый каталог, что крайне удобно (для меня).

Хотелось бы, что бы в случае создания новой ветки меркурий создавал каталог в определённом месте, имя которого соответствовало бы с именем ветки, и после обновлений складывал бы в этот каталог обновлённую версию исходного кода, а после удаления/слияния ветки - этот каталог удалялся бы.

Скажите пожалуйста, возможно ли такое физически? Если да, где можно почитать? (желательно, конкретно ссылку, а не "Google").

P.S. Если подобный функционал возможно реализовать в Git - буду благодарен за информацию по этому вопросу. Благодарю за внимание!

WolfAlone, немного сценарий не ясен. как я понимаю, в результате push в новую ветку, надо:

• создать новый каталог где-то (если надо)
• клонировать весь репозиторий, и там-же сделать переход на эту ветку.

для решения поставленной задачи нужно написать скрипт, который бы:

• 1) получал список всех веток
• 2) для каждой b:
  • 2.1) апдейт на ветку
  • 2.3) если каталог Z/b не существует, создаем его
  • 2.2) rsync туда каталог X/* (игнорируя все .hg*) в Z/b

потом этот скрипт нужно превратить в incoming хук
(не commit, т.к. commit-хук запускается на каждый changeset, т.е. если кто-то толкнул 10 ченджей, хук запустится 10 раз!)

проблема всего этого, в том, что ты связываешь концептуально 2 разных сущности в одно целое:
сущность "Репозиторий", и сущность "каталог для сервера" должны быть как можно меньше связаны (модульность!)
намного более правильное решение - вытягивать регулярно (каждый нод в свое время) изменения с серванта на конечные ноды.

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


Это сообщение отредактировал(а) bilbobagginz - 6.12.2011, 01:59

Да, примерно этого я и добиваюсь! Устал бороться со всякими "денверами" и пр. штуками. Причина банально проста. Многие разработчики работают на не безызвестной ОС семейства "Windows". При этом, почти все сервера, у нас работают на *nix.

Большая проблема в том, что всё это "счастье" зачастую настроено совсем не так, как должно быть.

Например, каких-то модулей нет, какие-то надо отключить и так далее... Всё "как надо" настроено на сервере (сервер предназначен исключительно для репозиториев кода + туда прикручен Apache-2 для просмотра конечного результата).

У сервера есть самодельная панель управления, в которой можно управлять созданием репозиториев и пр. мелочами. При этом, когда мы создаём репозиторий - к Apache автоматически добавляется виртуальный хост, смотрящий в папку c репозиторием.
*соответственно, в этой папке всегда лежит "stable-ветка"

По моим разумениям, дабы расширить функциональные возможности и максимально автоматизировать те процессы, которые можно автоматизировать, а так же исключить такие понятия как "FTP" и пр., которые отнимают порой не мало времени. Я решил, что не плохо было бы, когда разработчик (или группа), создаёт себе какую-то ветку с исходным кодом (для "тестов" так сказать) - эта ветка превращалась бы в новый виртуальный хост Apache, для того, что бы результаты работы можно было смотреть не только на "denwer", "Vertrigo" и т.п. "радостях", а на сервере, который настроен конкретно для того, что бы разработчики могли видеть, "результат на лицо".

Соответственно, при удалении/слиянии веток, не существующие ветки (и соответствующие им виртуальные хосты, директории и файлы в них) должны удаляться.

Набор скриптов управления Apache-2 - уже написан и успешно функционирует. Остлось, всё это дело прикрепить к Mercurial.

*Сервер репозиториев работает на платформе Debian 6 (если это как-то изменит дело).

Возможно я в чём-то не прав, поправьте пожалуйста!

bilbobagginz, я примного благодарен Вам за ответ! Он подтолкнул меня к одной (возможно, правильной) мысли. Но, я не совсем понимаю, какой именно модульности тут не хватает? Или, может быть я "не в ту сторону думаю"?

какая-то билиберда. как это "при удалении" веток ?!? удаления веток нет в меркюриал. есть "закрытие".
ты можешь удалить клон. но репозиторий всегда сохраняет историю.


у вас команда веб разработчиков и команда QA. 
из кусков инфы, у меня складывается сл. картина:
по причинам мне невидимым (видимо удобства для QA), 
вы смешали распределенный инструмент с централизованным. это принципиально ... не перспективно.
централизованный в этой связке компонент вас будет всегда оттягивать в зад.

вместо каждого разраба работающего на своем изолированном сервере linux/apache/db/hg clone,
(которые можно кинуть на минимальную виртуалку, бегущую со своей машины)

вы построили интересную, но сложную связку, которая:
1) генерит конфы для апача
2) генерит репы для девелов
3) связывает все это хитровы...нным кодом.

Это конечно же прикольно, но не уверен просто ли в поддержке, отладке и при проблемах.

по-моему, самый правильный вариант таков:
есть 1 репозитарий с малым количеством ВЕТОК (по терминологии "наименованные ветки" от Спольского)
допустим: default, legacy, experimental, team-bla, team-bla2, и т.п.
девелы работают со своими клонами, в какой-то одной из этих веток.
между данными ветками время от времени происходят сношения - слияния, "сбор ягодок", и т.д.
на каком-то своем простом апаче (в виртуальной машине), практически локально.
если каждый будет иметь свою БД, и вы используете миграции, вообще - сказка.

время от времени (напр. ежедневно) они свои outgoing И MQ могут бэкапить (по своему усмотрению) посредством копирования на какой-то удаленный бэкапный нетшер.
sizeof(outgoing) + sizeof(mq) << sizeof(весь общак)

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

конечно все это зависит от машин разработчиков. 

теперь процесс QA: проблема возможно в том, что у вас им приходится копаться в логах апача.
Так вот. эти логи мона кидать на центральный логхост.
на него установить какой-то logstash, и тогда можно искать логи для всех ото всех.
и не нужно их шарить.

в общем я не совсем вменяем сейчас, но если идея понятна...
то хорошо.

кстати для просмотра репозиториев очень уважаю rhodecode (без апача, чистый питон)


Это сообщение отредактировал(а) bilbobagginz - 7.12.2011, 04:08

bilbobagginz, ещё раз благодарю за помощь! На счёт "удаления" ветки, я "промахнулся", признаю. В принципе, вопрос про "удаление" веток, можно пока опустить, это не самое главное.

Но, все проблемы начинаются примерно вот с этого места:




*каждый имеет свою БД

Для каждого конкретного проекта, у нас создаётся отдельный сервер (Debian 6), в облаке. На сервер ставиться Mercurial + Apache + все необходимые модули + Сервер БД + возможно ещё какие-то плюшки, необходимые для данного конкретного проекта.

Смесь "централизованной" системы с "децентрализованной" происходит только отчасти. Как я уже упоминал, не редко встаёт такая проблема как: "у меня вот, всё работает". Выглядит всё это примерно так:

•  Кто-то работает на Linux/Unix
•  Кто-то работает на Windows
•  Кто-то использует "denwer", "vertrigo", "WAMP" и пр. "радости"
•  Кто-то использует "мануал, как установить LAMP в Ubuntu"
•  У кого-то хватает ума, поставить себе виртуальную машину, настроить её и настроить там Apache, как положено, в соответствии с требованиями к ПО (они доступны для всех разработчиков), соответственно, у кого-то ума не хватает...

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

Так же, проблема усугубляется тем, что не все разработчики собраны в стенах одного конкретного здания. Кого-то могут нанять на 1 проект, кто-то может жить достаточно далеко, или вообще не придти на работу и работать из дома. То есть, такого варианта, как:

•  Объяснить всем подробно что такое Linux
•  Придти ко всем по месту установки их рабочего компьютера, настроить ПО в соответствии со всеми требованиями
•  И т.д.

Такого варианта у нас к сожалению не предусмотрено, видимо, в виду не оправданных затрат в человеко-часах на индивидуальную работу с каждым.

Единственное верное, на мой взгляд решение в сложившейся ситуации:
1. Иметь "центральный" репозиторий, как "точку отчёта": "что мы сейчас имеем и в каком виде"
2. Выделить каждому разработчику (или каждой группе) по 1-му виртуальному серверу, для того, что бы исключить такие моменты, как:

•  у меня все работает, это у вас там сервер кривой!
•  у меня на "денвере" всё прекрасно пашет!
•  почему в Linux имена файлов регистро-зависимые? Поставьте туда "винду"!

То есть, в итоге мы в любом случае, не можем обойтись без того, что бы каждый разработчик (или группа) имела в своём распоряжении 1 виртуальных хост, настроенный 1 раз, в точности так же, как будет настрое конечный сервер данного проекта.

Не нравиться во всём это мне примерно следующее:
Не так давно, мы наконец-то избавились от такого понятия как (S)FTP и им подобных. Теперь, все желающие работают в NetBeans 7.Х к которому прикручен TortoiseHG. Такая связка даёт просто фантастическую скорость "заливки" исходников на конечный сервер по сравнению с заливкой исходников по FTP. При этом, TortoiseHG используется исключительно как HG-клиент для NetBeans. Я даже больше скажу! NetBeans автоматически находит установленный TortoiseHG и автоматом прикручивает его в роли клиента для HG-репозитория, что не может не радовать.

*по крайней мере, так происходит на WindowsXP/Windows-7 системах, коих у нас большинство.

Развиваю мысль далее:
Как мне кажется, если пойти неким другим путём, отличным от того, которого я хочу добиться, при этом не упуская из внимания тот факт, что каждому разработчику или группе разработчиков просто необходима своя "копия", "правильно настроенного" apache-2, то получиться примерно следующее:
1. У нас есть "центральный" репозиторий, к которому всё-таки прикручен Apache-2
2. У нас есть несколько веток, в которых (с которыми) работают какие-то конкретные люди
3. Для каждой группы (или конкретного девелопера) у есть либо заранее сгенерированный виртуальный хост, либо они постоянно дёргают админа "сделай мне виртуальный хост, мне залить и проверить надо", либо они сами лезут в панель управления и создают там себе виртуальный хост для тестов, что опять таки, требует дополнительного времени и трудозатрат.
4. После того, как каждый из них что-то "создал/написал/сделал" либо как-то ещё изменил исходный код, протестировал всё это на своём любимом "denwer" и пришёл к выводу, что у него всё работает - возникает необходимость закачать всё это добро на сервер, и удостовериться, что всё работает именно там, где оно должно работать, а не только лично у него.
5. Тут наступает необходимость использования FTP... На что тоже уходит лишнее время
5.1 Помимо того, что лишнее время уходит вообще на то, что бы просто воспользоваться FTP-клиентом, так же лишнее время (и трафик) уходит на то что бы закачать туда всё это добро.

Привожу наглядный пример:
Человек изменил 3 файла (1 вид, 1 модель, 1 контроллер), и заливает их на сервер, что бы посмотреть результат. Каждый из этих файлов распихан по разным папкам в общей куче исходного кода.

Вариант А:
Жмём "пуш ту мэйн серв" - через 10сек. можно смотреть результат

Вариант Б:
1. Идём в ФТП-клиент, открываем папку с исходниками, копаемся там, среди множества других выбираем 1 нужный файл, загружаем... Повторяем последнюю операцию ещё 2 раза.
2. Идём в ФТП-клиент, открываем папку с исходниками, загружаем вместо 3-х конкретных файлов, половину исходного кода, что бы не выискивать среди десятков и сотен других файлов какие-то конкретные, тратим кучу времени и трафика.


bilbobagginz, может быть, я опять что-то не до понимаю? Если это так - поправьте меня пожалуйста!

ты постоянно загружаешь новую инфу. TOO MUCH INFORMATION!
давай сосредоточимся на принципах:

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

ненужные сложности, ненужные компоненты системы и без того трудно дебажируемой.

то, что тебе надо для каждого пользователя добавлять что-то в конфиги апача - ПЛОХО.  это плохо масштабируется, это на каждого пользователя много изменений в общей картине.





Это сообщение отредактировал(а) bilbobagginz - 7.12.2011, 19:54

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

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

Звучать он (вопрос) будет приблизительно так:
Можно ли, при создании новой ветки в репозитории Mercurial (или в крайнем случае Git, или в самом крайнем случая, я готов даже на SVN согласиться) замутить какой-нибудь хитроумный хук, который будет вызывать файл на языке (ээмм... пусть будет файл .py или .sh) и передавать ему на вход 1-м параметром имя новой ветки? После чего (я ещё правда до конца не придумал как), этот файл создаст каталог, переключит ветку на "ветка_нэйм", и сделает внутри этого каталога "hg update", попутно добавив новый виртуальный хост к апачу.

Я конечно понимаю, что всё это OpenSource и в теории возможно всё (разобрать исходники, переписать под себя... можно даже Windows можно на ассемблере написать, если постараться, не спорю), но хотелось бы услышать какую-то более конкретную рекомендацию, используя стандартные средства, типа "хуков" если это конечно возможно.

Подозреваю, что какой-то момент в документации я где-то упустил... Если это действительно так - ткните пожалуйста в документацию, где будет описано нечто подобное. Возможно, в Mercurial такого сделать не получиться... в этом случае, я готов пожертвовать любимой системой контроля версий и заменить её на Git или SVN.

P.S. Благодарю за внимание!

То, что девелы не знают:

• что такое виртуальная машина
• знают зачем нужен линукс

просто не верю (ты сам веришь в это ?)

нужен централизованный источник знаний и инфы (Knowledge Base) для всех разработчиков (wiki/CMS). Это должно исходить как указание от начальства. с подписями и понтами. обязуха:

• новые работники должны будут прочитать какой-то минимальный список статей из сериии ЛикБез для ознакомления.
• регулярное чтение новостей вики (новые статьи, изменения, и т.д.)

Это уменьшит начальный поток вопросов обратно пропорционально качеству статей и их организации.
я не знаю как ваша фирма функционирует если люди не читают корреспонденцию.









Это сообщение отредактировал(а) bilbobagginz - 8.12.2011, 09:20

на это ты не дал ответ. 
просьба, не Выкай.

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


Хорошо!   

Ещё не плохо было бы прикрутить интерпретатор для комментариев. Например, если "коммитер" указал в комментарии, например: @ACTION:FORMAT_C то вызывается программа соответствующая этому действию. Возможна ли настройка поведения Mercurial подобным образом?

Добавлено через 25 секунд
*эх, юбилейный пост...   

я так понимаю ты сейчас ВСЕ будешь из меркюриал делать. может быть еще: ACTION:COFFE_ESPRESSO ?
определить какой файл можно еще и по .C и для этого есть еще и база данных mime types.
и действие с этим определяется ВНЕ системы ведения версий.

Честно говоря, не совсем понял о чём идёт речь

По поводу директивы, типа


я видимо не совсем правильно выразился. Насколько я помню, некоторые "Системы управления задачами" умеют "подвязываться" к системам контроля версий, среди которых и Mercurial. При этом, среди прочего, в какой-то "системе управления задачами" (не могу точно вспомнить вспомнить в какой), в комментариях к коммитам можно было указывать разнообразные директивы, которые означали например "задача #такая-то закрыта" или "изменить статус задачи N". То есть, некий (назовём его так) "коннектор" к Mercurial умеет читать комментарии к коммитам и на основе их выполнять какие-то действия. Соответственно, насколько я понимаю всю эту систему - чтение комментариев может происходить либо по CRON либо, при обращении к какой-то задаче (кто-то обратился к задаче, "система управления задачами" порылась по новым комментариям в репозитории, поискала там свои "директивы", если нашла - соответствующим образом изменила некоторые задачи и отобразила их (задачи или какую-то конкретную задачу).

Собственно, я хочу добиться практически аналогичного функционала, только с подходом немного "с другой стороны". Я хочу что бы не какая-то левая программа лазила по репозиторию, а сам Mercurial вызывал "ХУК" в случае, если произошло "такое-то" действие. Только, слегка более "точный" хук, нежели например, обычный "Commit".

P.S. Это возможно, без правки исходного кода и "костылей"?

выходим из меркуриала, и приходим к методологиям разработки 

Никакой (здравомыслящий) коннектор организации проектов/задач не должен слушать девелопера (который написал коммент), пославшего "фикс". Он может только присобачить в коммент номер/ID задачи, которую пытался решить.
а человек, который задал задачу решит: решена ли проблема, реализован ли функционал или нет.
Многое можно сделать с тэгами, если их парсить. Есть коннекторы, прослушивающие активность центрального сервера меркуриал (пулл в принципе), и парсящие комменты. Но они не определяют фикс это или еще нет.
Просто отображают список ченджей на странице проблемы/задачи, связанных с ней какой-то связью (принято ID задачи). Зкрытие же происходит: 
а) задавателем задачи
б) на уровне "системы управления задачами"

bilbobagginz, спасибо большое, с методологией разработки всё ясно. Видимо, та система управления проектами о которой я говорил была предназначена на 1-2чел., где такое поведение всё же допускалось. 

Но, я всё же хотел бы вернуться к вопросу: можно ли в Mercurial с помощью хука обработать комментарий коммита?