Comments 36
читаю эти статьи и дико горжусь выбором mercurial в своих проектах. простая и удобная DVCS.
ooshsmay allway ingredientsway ogetherawy. Ervesay ithway otatopay ipschay.Что это за заклинание?
UFO just landed and posted this here
UFO just landed and posted this here
на дисках с ntfs есть жеские ссылки.
Хотя в примерах именно Windows :)
C:\Users\Joel>
C:\Users\Joel>
Ну это же Joel — он известный любитель Windows и крайне эпатажных статей, призывающих под какие-нибудь очередные знамена. На этот раз, видимо, под знамена Mercurial, впрочем, как обычно, не объясняя ни разу, зачем и почему…
UFO just landed and posted this here
Я, в общем, и оригинал в своё время читал, и здесь за переводами внимательно слежу. Возможно, мне одному обилие фраз в повелительном наклонении («Запомните!», «поверьте!») и прочих, мягко говоря, спорных утверждений, выдаваемых за непреклонную истину (обычно обернутых во фразы типа «общепринято») кажется несколько странным стилем изложения для обучающих материалов, коими по идее должны быть эти статьи…
UFO just landed and posted this here
Текст на самом деле является художественной переработкой Mercurial: The Definitive Guide — порядок изложения и некоторые характерные ходы выдают. Переработка же произведена в характерном (по крайней мере, как мне кажется) для Joel стиле — выкинуть все объяснения (сложно, напугает новичков, зачем им), понабросать побольше красивых лозунгов («Mercurial — круто! Subversion — отстой! повторяйте за мной!») и разбавить историями про воображаемых коллег, косячки, красивую хипстерскую реальность кремниевой долины.
Некоторым нравится.
Некоторым нравится.
Единственное, что пока мне кажется неудобным — игнорирование папок (хотелось бы фиксировать структуру с пустыми папками). Несмотря на это попробую hg в будущих проектах.
Фиксировать структуру папок можно помещая в них пустые файлы.
Или создать build-скрипт, который позаботится о том, чтобы все необходимые папки были созданы. Мне этот вариант кажется более удобным, т.к. не нужно захламлять проект и более простым, т.к. список папок будет храниться в build-скрипте, что позволит его с легкостью изменять в будущем.
Есть ещё практика помещения в такие папки файликов вида .ignore с маской *
Может немного забегаю вперёд, но есть вопрос: какая практика ветвления/объединения при разработке используется чаще/удобнее: один локальный клон у одного центрального репозитория с ветками у одного пользователя или множество клонов центрального репозитория у одного пользователя?
Может на примере будет понятней, что хочется понять:
Есть production, staging и development сервера, есть несколько разработчиков, каждый из которых одновременно (в глобальных масштабах :) ) работает над несколькими фичами/багфиксами проекта. Можно организовать так, что у каждого сервера будет свой клон центрального репозитория и у разработчиков клон для каждой фичи/багфикса, можно использовать для каждого сервера/фичи ветки (branch), можно как-то комбинировать (ветки для серверов, клоны для фич).
Как лучше (проще поддерживать актуальность, удобней пользоваться и т. п.) и почему?
И ещё маленький вопросик — какие традиционные имена у основных репозиториев/веток (аналог TRUNK в Subversion)?
Может на примере будет понятней, что хочется понять:
Есть production, staging и development сервера, есть несколько разработчиков, каждый из которых одновременно (в глобальных масштабах :) ) работает над несколькими фичами/багфиксами проекта. Можно организовать так, что у каждого сервера будет свой клон центрального репозитория и у разработчиков клон для каждой фичи/багфикса, можно использовать для каждого сервера/фичи ветки (branch), можно как-то комбинировать (ветки для серверов, клоны для фич).
Как лучше (проще поддерживать актуальность, удобней пользоваться и т. п.) и почему?
И ещё маленький вопросик — какие традиционные имена у основных репозиториев/веток (аналог TRUNK в Subversion)?
UFO just landed and posted this here
Я думаю, шестая (последняя часть) именно об этом.
Если кратко, то есть разные практики, Джоэль (автор этого пособия) советует для веток заводить отдельные клоны репозитория.
Если кратко, то есть разные практики, Джоэль (автор этого пособия) советует для веток заводить отдельные клоны репозитория.
Как мне кажется, клоны удобны для небольших временных ответвлений, типа разработки фичи или фикса бага, то есть собственно для локального процесса разработки. А вот ветки хороши для организационного статического деления со строгим контролем прав, автоматическим тестированием, сборкой, публикацией по коммитам. Но это пока только взгляд со стороны, надо смотреть на практике.
Есть отличная статья от 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/
Если на русском, перевод тут: pqr7.wordpress.com/2010/10/10/a-guide-to-branching-in-mercurial/
UFO just landed and posted this here
Так как в 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
mercurial.selenic.com/wiki/Subrepository
stackoverflow.com/questions/2083393/mercurial-subrepos-how-do-you-create-them-and-how-do-they-work
почитайте про деревья в Hg
да, можно одним движением протолкнуть всё
да, можно одним движением протолкнуть всё
Sign up to leave a comment.
Hg Init: Часть 4. Исправляем ошибки