Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Программное обеспечение под *NIX системы > Mercurial, ветви

Автор: WolfAlone 5.12.2011, 12:16

Доброго времени суток! Настроил связку Mercurila + NetBeans + Apache 2. Всё работает просто замечательно! После коммита - меркурий (*Mercurial, HG) сливает файлы из репозитория в определённый каталог, что крайне удобно (для меня). Хотелось бы, что бы в случае создания новой ветки меркурий создавал каталог в определённом месте, имя которого соответствовало бы с именем ветки, и после обновлений складывал бы в этот каталог обновлённую версию исходного кода, а после удаления/слияния ветки - этот каталог удалялся бы. Скажите пожалуйста, возможно ли такое физически? Если да, где можно почитать? (желательно, конкретно ссылку, а не "Google"). P.S. Если подобный функционал возможно реализовать в Git - буду благодарен за информацию по этому вопросу. Благодарю за внимание!

Автор: bilbobagginz 6.12.2011, 01:49

WolfAlone, немного сценарий не ясен. как я понимаю, в результате push в новую ветку, надо: создать новый каталог где-то (если надо) клонировать весь репозиторий, и там-же сделать переход на эту ветку. для решения поставленной задачи нужно написать скрипт, который бы: 1) получал список всех веток 2) для каждой b: 2.1) апдейт на ветку 2.3) если каталог Z/b не существует, создаем его 2.2) rsync туда каталог X/* (игнорируя все .hg*) в Z/b потом этот скрипт нужно превратить в http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html (не commit, т.к. commit-хук запускается на каждый changeset, т.е. если кто-то толкнул 10 ченджей, хук запустится 10 раз!) проблема всего этого, в том, что ты связываешь концептуально 2 разных сущности в одно целое: сущность "Репозиторий", и сущность "каталог для сервера" должны быть как можно меньше связаны (модульность!) намного более правильное решение - вытягивать регулярно (каждый нод в свое время) изменения с серванта на конечные ноды. в общем, подход хука обычно означает, что тебе будет трудно расти. и хук надо умный писать. (даже просто при добавке новых веток. а если надо проверять, что ветки не закрыты, и закрытые - стирать, это еще код) намного проще вытягивать изменения. хотя может я не догоняю.

Автор: WolfAlone 6.12.2011, 20:03

Да, примерно этого я и добиваюсь! Устал бороться со всякими "денверами" и пр. штуками. Причина банально проста. Многие разработчики работают на не безызвестной ОС семейства "Windows". При этом, почти все сервера, у нас работают на *nix. Большая проблема в том, что всё это "счастье" зачастую настроено совсем не так, как должно быть. Например, каких-то модулей нет, какие-то надо отключить и так далее... Всё "как надо" настроено на сервере (сервер предназначен исключительно для репозиториев кода + туда прикручен Apache-2 для просмотра конечного результата). У сервера есть самодельная панель управления, в которой можно управлять созданием репозиториев и пр. мелочами. При этом, когда мы создаём репозиторий - к Apache автоматически добавляется виртуальный хост, смотрящий в папку c репозиторием. *соответственно, в этой папке всегда лежит "stable-ветка" По моим разумениям, дабы расширить функциональные возможности и максимально автоматизировать те процессы, которые можно автоматизировать, а так же исключить такие понятия как "FTP" и пр., которые отнимают порой не мало времени. Я решил, что не плохо было бы, когда разработчик (или группа), создаёт себе какую-то ветку с исходным кодом (для "тестов" так сказать) - эта ветка превращалась бы в новый виртуальный хост Apache, для того, что бы результаты работы можно было смотреть не только на "denwer", "Vertrigo" и т.п. "радостях", а на сервере, который настроен конкретно для того, что бы разработчики могли видеть, "результат на лицо". Соответственно, при удалении/слиянии веток, не существующие ветки (и соответствующие им виртуальные хосты, директории и файлы в них) должны удаляться. Набор скриптов управления Apache-2 - уже написан и успешно функционирует. Остлось, всё это дело прикрепить к Mercurial. *Сервер репозиториев работает на платформе Debian 6 (если это как-то изменит дело). Возможно я в чём-то не прав, поправьте пожалуйста! bilbobagginz, я примного благодарен Вам за ответ! Он подтолкнул меня к одной (возможно, правильной) мысли. Но, я не совсем понимаю, какой именно модульности тут не хватает? Или, может быть я "не в ту сторону думаю"?

Автор: bilbobagginz 7.12.2011, 04:02

Цитата(WolfAlone @  6.12.2011,  19:03 ) Соответственно, при удалении/слиянии веток, не существующие ветки (и соответствующие им виртуальные хосты, директории и файлы в них) должны удаляться какая-то билиберда. как это "при удалении" веток ?!? удаления веток нет в меркюриал. есть "закрытие". ты можешь удалить клон. но репозиторий всегда сохраняет историю. у вас команда веб разработчиков и команда QA.  из кусков инфы, у меня складывается сл. картина: по причинам мне невидимым (видимо удобства для QA),  вы смешали распределенный инструмент с централизованным. это принципиально ... не перспективно. централизованный в этой связке компонент вас будет всегда оттягивать в зад. вместо каждого разраба работающего на своем изолированном сервере linux/apache/db/hg clone, (которые можно кинуть на минимальную виртуалку, бегущую со своей машины) вы построили интересную, но сложную связку, которая: 1) генерит конфы для апача 2) генерит репы для девелов 3) связывает все это хитровы...нным кодом. Это конечно же прикольно, но не уверен просто ли в поддержке, отладке и при проблемах. по-моему, самый правильный вариант таков: есть 1 репозитарий с малым количеством ВЕТОК (по терминологии "наименованные ветки" от http://hginit.com/) допустим: default, legacy, experimental, team-bla, team-bla2, и т.п. девелы работают со своими клонами, в какой-то одной из этих веток. между данными ветками время от времени происходят сношения - слияния, "сбор ягодок", и т.д. на каком-то своем простом апаче (в виртуальной машине), практически локально. если каждый будет иметь свою БД, и вы используете миграции, вообще - сказка. время от времени (напр. ежедневно) они свои outgoing И MQ могут бэкапить (по своему усмотрению) посредством копирования на какой-то удаленный бэкапный нетшер. sizeof(outgoing) + sizeof(mq) << sizeof(весь общак) далее - более. когда их штука готова они ее пушат и мержат в свою ветку на серванте. т.е. ветка - эволюционирует. для просмотра общака можно юзать тот же инструментарий. но количество "виртуальных" хостов" можно будет сократить до 1-го. конечно все это зависит от машин разработчиков.  теперь процесс QA: проблема возможно в том, что у вас им приходится копаться в логах апача. Так вот. эти логи мона кидать на центральный логхост. на него установить какой-то logstash, и тогда можно искать логи для всех ото всех. и не нужно их шарить. в общем я не совсем вменяем сейчас, но если идея понятна... то хорошо. кстати для просмотра репозиториев очень уважаю rhodecode (без апача, чистый питон)

Автор: WolfAlone 7.12.2011, 12:13

bilbobagginz, ещё раз благодарю за помощь! На счёт "удаления" ветки, я "промахнулся", признаю. В принципе, вопрос про "удаление" веток, можно пока опустить, это не самое главное. Но, все проблемы начинаются примерно вот с этого места: Цитата(bilbobagginz @  7.12.2011,  04:02 ) на каком-то своем простом апаче (в виртуальной машине), практически локально. Цитата(bilbobagginz @  7.12.2011,  04:02 ) если каждый будет иметь свою БД, и вы используете миграции, вообще - сказка. *каждый имеет свою БД Для каждого конкретного проекта, у нас создаётся отдельный сервер (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, может быть, я опять что-то не до понимаю? Если это так - поправьте меня пожалуйста!

Автор: bilbobagginz 7.12.2011, 19:53

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

Автор: WolfAlone 7.12.2011, 22:52

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

Автор: bilbobagginz 8.12.2011, 09:05

Цитата(WolfAlone @  7.12.2011,  21:52 ) чем каждому девелоперу разжевывать, что такое виртуальная машина, зачем нужен Linux, почему у нас сервера работают на нём, зачем все имена файлов нужно писать в нижнем регистре... - это просто каторга! То, что девелы не знают: что такое виртуальная машина знают зачем нужен линукс просто не верю (ты сам веришь в это ?) нужен централизованный источник знаний и инфы (Knowledge Base) для всех разработчиков (wiki/CMS). Это должно исходить как указание от начальства. с подписями и понтами. обязуха: новые работники должны будут прочитать какой-то минимальный список статей из сериии ЛикБез для ознакомления. регулярное чтение новостей вики (новые статьи, изменения, и т.д.) Это уменьшит начальный поток вопросов обратно пропорционально качеству статей и их организации. я не знаю как ваша фирма функционирует если люди не читают корреспонденцию.

Автор: bilbobagginz 8.12.2011, 09:23

Цитата(bilbobagginz @  7.12.2011,  18:53 ) когда все пишут в один репозиторий и разные ветки - плохо (взрыв имен веток!), долгий клон. на это ты не дал ответ.  просьба, не Выкай.

Автор: WolfAlone 8.12.2011, 12:12

Цитата(bilbobagginz @  8.12.2011,  09:23 ) Цитата(bilbobagginz @  7.12.2011,  18:53 Найти цитируемый пост) когда все пишут в один репозиторий и разные ветки - плохо (взрыв имен веток!), долгий клон. на это ты не дал ответ.  Веток будет я думаю не очень много, в пределах дюжины. При этом, каждый будет знать свою и несколько смежных, которые отвечают за ту же часть программы. Цитата(bilbobagginz @  8.12.2011,  09:23 ) просьба, не Выкай. Хорошо!

Автор: WolfAlone 9.12.2011, 02:43

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

Автор: bilbobagginz 9.12.2011, 09:40

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

Автор: WolfAlone 9.12.2011, 13:21

Цитата(bilbobagginz @  9.12.2011,  09:40 ) определить какой файл можно еще и по .C и для этого есть еще и база данных mime types. Честно говоря, не совсем понял о чём идёт речь По поводу директивы, типа Цитата(bilbobagginz @  9.12.2011,  09:40 ) ACTION:COFFE_ESPRESSO я видимо не совсем правильно выразился. Насколько я помню, некоторые "Системы управления задачами" умеют "подвязываться" к системам контроля версий, среди которых и Mercurial. При этом, среди прочего, в какой-то "системе управления задачами" (не могу точно вспомнить вспомнить в какой), в комментариях к коммитам можно было указывать разнообразные директивы, которые означали например "задача #такая-то закрыта" или "изменить статус задачи N". То есть, некий (назовём его так) "коннектор" к Mercurial умеет читать комментарии к коммитам и на основе их выполнять какие-то действия. Соответственно, насколько я понимаю всю эту систему - чтение комментариев может происходить либо по CRON либо, при обращении к какой-то задаче (кто-то обратился к задаче, "система управления задачами" порылась по новым комментариям в репозитории, поискала там свои "директивы", если нашла - соответствующим образом изменила некоторые задачи и отобразила их (задачи или какую-то конкретную задачу). Собственно, я хочу добиться практически аналогичного функционала, только с подходом немного "с другой стороны". Я хочу что бы не какая-то левая программа лазила по репозиторию, а сам Mercurial вызывал "ХУК" в случае, если произошло "такое-то" действие. Только, слегка более "точный" хук, нежели например, обычный "Commit". P.S. Это возможно, без правки исходного кода и "костылей"?

Автор: bilbobagginz 10.12.2011, 11:23

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

Автор: WolfAlone 10.12.2011, 13:06

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

Автор: WolfAlone 19.12.2011, 23:35

Доброго времени суток! Дабы не плодить темы-клоны я бы хотел немного переформулировать один из последних вопросов в этой теме. Мы уже говорили о "привязке" отдельного каталога к каждой из веток в Mercurial и некоторых других VCS. Недавно, волей случая я опять столкнулся с такой системой контроля версий как SNV... Собственно, вопрос: существует ли, какая-нибудь система контроля версий, доступ к которой можно осуществлять удалённо (распределённая она или нет - особого значения не имеет), которая бы умела синхронизировать свою файловую систему с файловой системой сервера? Желательно, что бы для этой системы была поддержка NetBeans или хотя бы клиенты под Windows и Linux (Debian/SuSE и их производных). Не так давно, один человек показал мне, как устроена система SVN. Как выяснилось, в ней нет вообще такого понятия как "ветка", в принципе. По сути, репозиторий представляет из себя набор каталогов, за состоянием которых SVN следит. После изменения (коммита) каких-либо данных, можно слить ВСЮ ФС  из SVN'a в какой-то определённый каталог. И всё бы оно хорошо (и поддержка в NetBeans встроенная есть, и контроль прав и пр.), вот только одно плохо - если проект заключается в 1-10МБ кода, я бы ещё пережил полное копирование всех файлов из проекта на HDD сервера. Но, если проект будет занимать 100Мб, в нём будет 1000 файлов и с ним будут работать 30-50 человек, которые постоянно что-то будут комитить, и после каждого коммита (или ещё какого-то изменения) - всё будет повторно сливать на HDD (то есть, не только те файлы, которые изменились, а вообще все, которые там есть) - то это начисто положит жесткий диск и вообще убьёт всю производительность. Собственно, вопрос второй: возможно существует кака-то система контроля версий, соответствующая выше указанным требованиям, которая умеет после изменений синхронизировать свою ФС (файловую систему) с ФС сервера? Если говорить точнее, я преследую одну основную цель: разделить на уровне репозитория (с помощью веток, каталогов, суб-репозиториев или чего угодно) несколько разных версий одного и того же проекта, при этом каждая из версий должна лежать в отдельном (своём) каталоге на сервере. P.S. Может я конкретно не туда смотрю? Вот уже неделю перечитываю весь найденный материал для самых разнообразных VCS (систем контроля версий), среди которых: GIT, Mercrial, SVN. И никак не могу до конца понять, возможна ли вообще реализация чего-то подобного в какой либо из этих систем? Почему-то на ум не приходит ни "ДА" ни "НЕТ". Я конечно понимаю, что можно совершенно законно "разломать" исходик того же Mercurial и сделать из него то, что мне хочется. Но, тогда встанет вопрос поддержки в актуальном состоянии версии этого самого "клона", что явно мне "не по зубам". У меня нет ни ресурсов, ни желания, ни возможности делать и поддерживать форк Mercurial или какой-то другой VCS.

Автор: bilbobagginz 20.12.2011, 23:35

Цитата(WolfAlone @  19.12.2011,  22:35 ) Собственно, вопрос: существует ли, какая-нибудь система контроля версий, доступ к которой можно осуществлять удалённо (распределённая она или нет - особого значения не имеет), которая бы умела синхронизировать свою файловую систему с файловой системой сервера? Желательно, что бы для этой системы была поддержка NetBeans или хотя бы клиенты под Windows и Linux (Debian/SuSE и их производных). это делают ВСЕ из тобой перечисленных решений, в рамках процесса работы. процесс работы распределенных систем похож. у централизованной системы принцип немного другой. ВСЕ из них синхронизируются с каталогом своего "отца" (разным механизмом, но все это делают) ВСЕ из них поддерживают концепцию параллельной разработки модифицированных веток со слиянием меж ними. ВСЕ из них работают и удаленно и не удаленно, но для каждого коммита централизованных нужна связь с сервантом. ВСЕ из них позволяют контроль доступа к ресурсам репозитория по разным параметрам (включая ветки, пользователи, группы, и т.д.) Как я тебе раньше говорил: начни со сценария и требований, и потом выбирай решение. Далее требования и спецификации повесь на "стенгазету" своей организации, и заставь всех по ней работать. чтобы все знали куда делать коммит/пуш, кто отвечает за мерж, и т.д. Добавлено через 2 минуты и 47 секунд кстати tortoisehg умеет делать http://tortoisehg.bitbucket.org/manual/1.0/changelog.html#message-parsing при нужде можно даже заставлять пользователя (своей конфигой программы) запихивать в коммит мессагу идентификатор. (он при коммите без идентификатора заорет на пользователя)

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)