читаю эти статьи и дико горжусь выбором mercurial в своих проектах. простая и удобная DVCS.
ooshsmay allway ingredientsway ogetherawy. Ervesay ithway otatopay ipschay.
Что это за заклинание?
Поросячий латинский. «Волшебный кролик» в исполнении программистов. Ну и шуточки.
Mercurial воспользуется «жёсткими ссылками» (hard links)

Это справедливо видимо только для *nix систем, т.к. в windows такого поведения не наблюдается
NTFS умеет хардлинки. И под виндами Mercurial их тоже использует. Точно.
сейчас склонировал с одного локального репозитория в соседний — никаких жестких ссылок (Win 7, NTFS)
скорее всего, вы заблуждаетесь. почитайте ru.wikipedia.org/wiki/Hardlink для начала.
ок. проверил еще раз более тщательно на свежем репзитории — действительно работает, спасибо:)

Но, все-равно в статье нужно уточнить, что жесткие ссылки создаются только для структуры самого репозитория, а не файлов в нем.
Ну правильно, ведь «рабочая копия» заведомо меньше размером, чем вся история
на дисках с ntfs есть жеские ссылки.
Хотя в примерах именно Windows :)
C:\Users\Joel>
Ну это же Joel — он известный любитель Windows и крайне эпатажных статей, призывающих под какие-нибудь очередные знамена. На этот раз, видимо, под знамена Mercurial, впрочем, как обычно, не объясняя ни разу, зачем и почему…
На этот раз, видимо, под знамена Mercurial, впрочем, как обычно, не объясняя ни разу, зачем и почему…
«Часть 4» в заголовке топика и ссылки на предыдущие части, вы, надо понимать, предпочли не заметить?
Я, в общем, и оригинал в своё время читал, и здесь за переводами внимательно слежу. Возможно, мне одному обилие фраз в повелительном наклонении («Запомните!», «поверьте!») и прочих, мягко говоря, спорных утверждений, выдаваемых за непреклонную истину (обычно обернутых во фразы типа «общепринято») кажется несколько странным стилем изложения для обучающих материалов, коими по идее должны быть эти статьи…
А. Ну я не вчитывался в собственно статьи, каюсь — в своё время освоил hg самостоятельно.

В принципе, странный стиль, согласен. С другой стороны, текст для полных новичков и различные оговорки и километровые сноски могут навредить. Discuss?
Текст на самом деле является художественной переработкой Mercurial: The Definitive Guide — порядок изложения и некоторые характерные ходы выдают. Переработка же произведена в характерном (по крайней мере, как мне кажется) для Joel стиле — выкинуть все объяснения (сложно, напугает новичков, зачем им), понабросать побольше красивых лозунгов («Mercurial — круто! Subversion — отстой! повторяйте за мной!») и разбавить историями про воображаемых коллег, косячки, красивую хипстерскую реальность кремниевой долины.

Некоторым нравится.
Единственное, что пока мне кажется неудобным — игнорирование папок (хотелось бы фиксировать структуру с пустыми папками). Несмотря на это попробую hg в будущих проектах.
Фиксировать структуру папок можно помещая в них пустые файлы.
Или создать build-скрипт, который позаботится о том, чтобы все необходимые папки были созданы. Мне этот вариант кажется более удобным, т.к. не нужно захламлять проект и более простым, т.к. список папок будет храниться в build-скрипте, что позволит его с легкостью изменять в будущем.
спасибо, я читал про эти варианты. только не греют они душу)
Есть ещё практика помещения в такие папки файликов вида .ignore с маской *
Может немного забегаю вперёд, но есть вопрос: какая практика ветвления/объединения при разработке используется чаще/удобнее: один локальный клон у одного центрального репозитория с ветками у одного пользователя или множество клонов центрального репозитория у одного пользователя?

Может на примере будет понятней, что хочется понять:
Есть production, staging и development сервера, есть несколько разработчиков, каждый из которых одновременно (в глобальных масштабах :) ) работает над несколькими фичами/багфиксами проекта. Можно организовать так, что у каждого сервера будет свой клон центрального репозитория и у разработчиков клон для каждой фичи/багфикса, можно использовать для каждого сервера/фичи ветки (branch), можно как-то комбинировать (ветки для серверов, клоны для фич).

Как лучше (проще поддерживать актуальность, удобней пользоваться и т. п.) и почему?

И ещё маленький вопросик — какие традиционные имена у основных репозиториев/веток (аналог TRUNK в Subversion)?
какая практика ветвления/объединения при разработке используется чаще/удобнее
ну вот есть mercurial.selenic.com/wiki/WorkingPractices — выбирайте/спрашивайте более предметно.
какие традиционные имена у основных репозиториев/веток
никаких. есть только tip — закладка на последний коммит.
Я думаю, шестая (последняя часть) именно об этом.
Если кратко, то есть разные практики, Джоэль (автор этого пособия) советует для веток заводить отдельные клоны репозитория.
Как мне кажется, клоны удобны для небольших временных ответвлений, типа разработки фичи или фикса бага, то есть собственно для локального процесса разработки. А вот ветки хороши для организационного статического деления со строгим контролем прав, автоматическим тестированием, сборкой, публикацией по коммитам. Но это пока только взгляд со стороны, надо смотреть на практике.
Есть отличная статья от Steve Losh, в которой рассмотрены разные практики с их плюсами и минусами: stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Если на русском, перевод тут: pqr7.wordpress.com/2010/10/10/a-guide-to-branching-in-mercurial/
Спасибо, добавили информации к размышлению :)
Жаль, что в цикле статей нет ничего о rebase
rebase — это следствие локальных по умолчанию веток в git. лично меня вполне устраивает шаринг по умолчанию всего кода — мне нечего скрывать от коллег ;)
рискну предложить почитать «Programmer Insecurity» (по ссылке перевод на русский).
причем тут git? и кого скрывать? я не понимаю о чем вы.

Вот тут отличная статья про сравнение rebase и merge Mercurial workflows: mainline workflow

Мне просто не нравиться постоянные мерджи и миллирды веток в истории правок. Вот так выглядит наш репозиторий:

А. Нууу… для таких случаев в коробке лежит mercurial.selenic.com/wiki/RebaseExtension
Да я знаю что они есть, обидно что Джоель не написал про rebase, transplant, purge и прочих клёвых расширениях для меркуриала.
Так как в Hg хранить модули проекта, которые хочется менеджить отдельно друг от друга? Это должны быть отдельные репозитории? Насколько это удобно? Можно ли сделать update для всех модулей из всех репозиториев одним движением руки?
Да, можно сделать все модули отдельными репозиториями. А с помощью функционала «subrepo» можно делать update для всех связанных репозиториев одной командой.

mercurial.selenic.com/wiki/Subrepository

stackoverflow.com/questions/2083393/mercurial-subrepos-how-do-you-create-them-and-how-do-they-work
почитайте про деревья в Hg

да, можно одним движением протолкнуть всё
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.