Доброго времени суток! Подскажите пожалуйста, что можно почитать о системе контроля версий Merciurial? В частности интересует следующая информация:

• "Стратегия" работы с репозиторием (так это называется в руководстве по SVN), то есть принципы, методы, варианты, ветвление, слияние и так далее
• Клиенты для Mercurial, примеры работы с ними (всё, что выходит за рамки: "давайте возьмём TortoiseHg, сделаем репозиторий и создадим там 2 текстовых файла". Что-нибудь посложнее)
• Командная работа над кодом (примеры, приёмы, варианты и так далее)
• Доступ к репозиторию, варианты, протоколы (http[s], ssh и пр.), права доступа и т.д.

Говоря проще - очень интересует какое-то объёмное руководство, примерно такое же, как есть у SVN. Можно по частям. Главное, что бы материал был написан профессионально или хотя бы со знанием дела, а не очередной копией конфигурационного файла nginx, быстренько раскопированной на пару сотен блогов.

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

bilbobagginz, благодарю за предложение, но ищу я к сожалению не контент, а наиболее оптимальный набор ПО для разработки "всеобъемлющего "комбайна" способного выполнять полный цикл обслуживания всех процессов разработки ПО. Ничего дельного не нашлось, тот же Redmine это 3-4% от того, что реально нужно. ChiliProject - только недавно вышел в виде "stable", ещё не успели "обкатать", проверить... Subversion, не смотря на все свои плюсы (свой собственный протокол, поддержка авторизации и контроля доступа "из коробки" и т.п.) слегка тормозит, Mercurial как-то "хреновато" на мой взгляд интегрирован в NetBeans (тут конечно возможно я не прав, и в т.ч. и по этому разыскиваю документацию на Mercurial). Кстати, "Guide" и перевод чего-то там от Mercurial на русский язык (там где много страниц) - лучше б вообще не переводили... это просто ужас! К тому же, даже такую элементарную вещь, как "проталкивание" кода из одного репозитория в другой в Mercurial - описана крайне скудно, я бы даже сказал "кусками".

Интернет кишит плодами "КэтрлЦэ'шников" и "рерайтеров", из-за чего найти что-то хотя бы издали напоминающее какой-то толковый мануал - крайне сложно.

Документацию я не игнорирую, просто я не могу по каждому пункту из всего набора - изучить весь талмуд, только для того, что бы понять, что "это нам не подходит". Всё, между чем я "прыгаю", есть будущие части единого комплекса. Например, по SVN я нашёл более ли менее приличные "документы", прочитал из них примерно 40%, понял всю "соль", и принял информацию ко вниманию.

Приведу другой пример. Что нужно для разработки ПО помимо самого компилятора/интерпретатора/ect.? Конечно же среда, в которой будет происходить написание кода! По многим параметрам, личным, религиозным, массовым и прочим убеждениям и убеждениям - на данный момент был выбран NetBeans 7. С SVN'ом он дружит относительно неплохо. Заставить его так же дружить с Mercurial (в рамках командной разработки) - мне не удалось. И тут конечно же появляются 2 варианта ответа на вопрос: "почему?":
1. У меня не хватило каких-то навыков, что бы сделать "как надо"
2. Сделать "как надо" с помощью имеющихся средств - просто не представляется возможным

Собственно, этот рассказ можно продолжать очень долго... Я постараюсь подвести итог и ответить на вопросы.

Зачем я "прагаю" с пакета на пакет? Пытаюсь найти наиболее оптимальное решение (кстати так делаю не только я, например, разработчики Ubuntu тоже иной раз грешат чем-то подобным).

Зачем мне это нужно? Что бы найти "золотую середину" и чётко определиться с тем, что уже написано и можно использовать в готовом виде, а что придётся писать/переписывать/дописывать самостоятельно.

Что будет в конечном итоге? В конечном итоге будет нечто на подобии очередного дистрибутива ОС (аля "Ubuntu Server") призванного решать определённый круг задач. Проще говоря, это будет узкоспециализированный дистрибутив на базе Debian 6 (или более новой версии Debian к моменту завершения работ), с некоторыми обновлёнными пакетами ПО и другими доработками. Либо, это может быть какой-то отдельный дистрибутиво-независимый набор/пакет типа WebMin или ISPManager (*исключительно для примера) для nix OS.

P.S. Если кто-то располагает информацией по поводу наиболее оптимальной связки: VCS (*Version Control System) + IDE (желательно кросс платформенная, с максимальной интеграцией с этой самой VCS) - буду при много благодарен, если Вы этой информацией поделитесь. Проще говоря, интересует полномасштабный инструмент для работы команды программистов.

Интересует любая информация по теме. В частности, интересуют кратчайшие пути развёртывания выше описанного комплекса, без разнообразных "извращений", типа:
Спереди мы поставим nginx, сзади apache, посередине на всякий случай воткнём lighttpd, а в самом конце сервер mercruial, при этом авторизация будет проходить по SSL протоколу через 3-й сервер, на котором установлен RADIUS, база которого находиться на 5-ом сервере, подключение к которому происходит по защищённому IPSec-каналу, трафик которого идёт через 6-ой сервер, на котором расположен 3-х уровневый файрвол и т.д.

Системой должны пользоваться не только гуру *nix, а ещё и "простые смертные", которым чем проще - тем лучше (думаю, все слышали о таком принципе как KISS [если не слышали, можно почитать здесь: http://ru.wikipedia.org/wiki/KISS_(%D0%BF%...86%D0%B8%D0%BF)]. Вот именно этому принципу мне и хотелось бы следовать).

Добавлено через 4 минуты и 4 секунды
Говоря ещё короче: с удовольствием выслушаю рассказ на тему "как мы разрабатываем ПО". То есть, IDE, VCS, командная работа и так далее. Можно в подробностях, исключая мельчайшие детали (типа, запуск среды разработки, набор кода и т.п.)

А так же, хотелось бы услышать Ваше мнение на темы:
"Я выбрал эту IDE по тому, что..."
"Мы пользуемся этой VSC по тому, что..."

ну и так далее.

Только не нужно пожалуйста сорить в теме фразами типа: "по тому, что мне бабушка в автобусе сказала на ухо, что *** - это круто!"

это изначально проигрышный девиз.
потому что "все" процессы разработки ПО постоянно пополняются новыми идеями и элементами, а некоторые уходят.
Кроме того, не при любом масштабе имеет смысл иметь целый арсенал инструментов.
Кроме того, не для каждого проекта даже в одной и той же фирме/организации имеет смысл внедрять одинаковый арсенал.

Короче слишком много букв. 
определись с масштабом команды и кода. 
когда с этим будет всё ясно, многие вопросы сами по себе отойдут.
если утверждаешь, что твой проект открытый, я бы рекомендовал коммерческий продукт, который дает опен сорсникам бесплатное решение.
фирма называется Atlassian. они купили фирму BitBucket, разработчика одноименного online ресурса по хостингу и ведению проектов на основе DVCS mercurial.

Через битбакет настроишь себе репы с доступами и т.д. (по докам)

a jira - и возможно остальные компоненты (confluence, etc.) для остальных нужд.
У них очень гибкое и настраиваемое решение для инфо-системы, которая понадобится для нужд фирмы разработчика.
джирой пользуется пол мира.

http://www.atlassian.com/software/jira/pri...type=opensource
можно подкрутиться к джире со всех стандартных сред разработки.
джира умеет прикручиваться к меркьюриал репам.

Кстати, если есть проблемы с английским,  решай их сам

У меня нет никаких проблем с английским уже много лет. Хотя, желание иметь документы на родном языке - присутствует.

P.S. Я разве говорил, что у меня есть какие-то проблемы с английским?

это самая неважная деталь моего поста.

bilbobagginz, 
пытаюсь подружить джиру и битбакет. точнее плагин джиры fisheye, чтобы битбакет репозиторий можно было в джире просматривать.
я на jira studio hosted. есть у них там такой сервис. но выяснилось, что джира студио на данный момент "bundled" только с SVN и заставить FishEye работать с чем то кроме него нельзя.
связывался с атлассианом, пишет что в планах включить гит и меркуриал в бандл только через несколько месяцев.
подобный опыт имеется, мож чего подскажешь?

идеи:
1) джира сама по себе поддерживает репозитории меркьюриал. можно сделать клон, у которого будет post-push/post-commit хук, который сделает push на битбакет.
2) битбакет умеет себя представлять как SVN ;-)

Хотелось бы уточнить ещё 1 вопрос касательно Mercurial. Есть у нас на удалённом сервере репозиторий Mercurial, всё работает как надо, пользователи по SSH туда-суда ходят, качают и так далее.

Вопрос: можно ли как-то из папки с репозиторием (для примера она находиться по такому пути [если это принципиально]: /repos/demo_rep_hg1/) папку для веб-сервера (виртуальный хост для апача)? То есть, я хочу, что бы после коммита человек мог зайти по специальному адресу, и посмотреть, как работает его "коммит".

Собственно, проблема в том, в папке с репозиторием лежат конкретно история изменений файлов, а не сами файлы. Что бы достать последнюю редакцию файлов, на данный момент я просто клонирую репозиторий. Чисто теоретически, можно поставить задание в CRON, что бы он постоянно клонировал все репозитории в папки веб-сервера, но по моему, это как-то не продуктивно. То есть, будет либо задержка в N-минут перед тем, как содержимое репозитория станет доступно на веб-сервере, либо это будет создавать постоянную, мало полезную нагрузку на процессор.

Возможно есть какие-то более логичные способы?

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

если я правильно понимаю "работают" - какие-то каталоги файлов представляют из себя веб-приложение.

трудно давать конкретные ответы, но нужно помнить, что в общем:
version control != deployment

кроме того, просто клонирования не достаточно, нужно какой-то update делать. посчитай сколько места клоны будут занимать.
думаю, намного эффективнее делать rsync с репозитория в нужный каталог, который будет сервиться.
делать это можно "по поступлению" (скриптом changegroup hook). 
т.е. когда кто-то делает push в репозиторий поступает группа changeset-ов. это и является триггером.
http://hgbook.red-bean.com/read/handling-r...with-hooks.html

там есть момент, о котором надо подумать: 
если в данный репозиторий push-ат только удаленно, и никто не commit-ит локально, этого достаточно.
если же кто-то может за-commit-иться, то надо будет и об этом подумать, и сделать hook.


З.Ы. если бы я был модером, я бы на тебя наорал, а тему разрубил на 2.


Это сообщение отредактировал(а) bilbobagginz - 27.8.2011, 03:48

Спасибо за информацию, и ссылку!


Намёк понял!