0,0
рейтинг
23 ноября 2010 в 13:40

Разработка → Hg Init: Часть 2. Основы Mercurial перевод

Это вторая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Возможно, вы захотите прочитать и первую часть «Переобучение для пользователей Subversion».

Даже если вы работаете в одиночку, то вам стоит использовать Mercurial. Так вы сможете получить все прелести контроля версий. Эта часть покажет насколько просто добавить каталог в Mercurial, чтобы с легкостью отслеживать предыдущие версии.

Часть 2. Основы Mercurial



Mercurial — это система контроля версий. Разработчики используют ее для администрирования исходного кода. У нее два основных назначения:
  1. Она хранит все предыдущие версии каждого файла
  2. Она может объединить разные версии вашего кода, то есть сотрудники могут независимо работать над кодом и затем объединять свои изменения




Без Mercurial вы могли бы попытаться сохранить предыдущие версии, просто создавая много копий каталога с кодом:



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

Большинство людей работают с Mercurial через интерфейс командной строки. Так можно работать в Windows, Unix, и Mac. Команда для Mercurial — это hg:



Если выполнить hg без параметров, то вы получите список наиболее часто используемых команд. Вы можете также попробовать выполнить hg help для получения полного списка команд.

Для того чтобы воспользоваться преимуществами контроля версий, вам нужен репозиторий. Репозиторий хранит все предыдущие версии всех ваших файлов. На самом деле, для экономии места на диске, все предыдущие версии не будут храниться — будет храниться только компактный список изменений.

В старые времена заиметь репозиторий было большим делом. Вам было необходимо иметь центральный сервер и нужно было установить на него программное обеспечение. Mercurial — распределенная система, так что вы можете использовать ее без модного центрального сервера. Вы можете пользоваться Mercurial, используя один только свой компьютер. А заполучить репозиторий супер просто: вы просто идете в каталог с вашим кодом…



… и выполняете команду hg init:



hg init
создает репозиторий.


Минуточку, а разве что-то произошло? Выглядит так, словно ничего не поменялось. Нет, если вы присмотритесь получше, то увидите, что появился новый каталог .hg:



Это и есть репозиторий! Это каталог со всем, что нужно Mercurial для работы. Настройки, предыдущие версии файлов, теги, лишняя пара носков на случай дождя, и прочее. Не лазьте туда. Вам почти всегда не стоит возиться с этим каталогом самостоятельно.

Ну хорошо, раз у нас теперь есть свежеиспеченный репозиторий, то мы захотим добавить в него все исходные файлы. Это тоже просто: нужно лишь выполнить hg add.



hg add
помечает файлы как запланированные для добавления в репозиторий. Файлы на самом деле не будут добавлены до тех пор, пока вы не зафиксируете изменения.


Остался еще один шаг… вам нужно зафиксировать ваши изменения. Какие изменения? Факт добавления всех этих файлов.

Почему вы вынуждены фиксировать изменения? При работе с Mercurial фиксирование изменений означает: «Эй, вот как файлы сейчас выглядят, так их и запомни, пожалуйста». Это как создание копии всего каталога… каждый раз, когда у вас есть что-то измененное, и оно вам типа нравится, то вы фиксируете изменения.

hg commit
сохраняет текущее состояние всех файлов в репозиторий.




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



После сохранения и выхода из редактора ваши изменения будут зафиксированы.

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



hg log
отображает историю изменений, зафиксированных в репозитории.


Давайте изменим файл и посмотрим, что получится.



Так как мы сделали изменение, то можем его зафиксировать при помощи hg commit:



Обратите внимание, что Mercurial догадался, что только один файл, a.txt, изменен:



А теперь, после того как я закоммитил (зафиксировал изменения), давайте посмотрим на историю:



Как любой нынешний блоггер, Mercurial помещает самое новое в начало.

Я собираюсь сделать еще одно изменение, просто чтобы потешить себя.



Коммичу (фиксирую изменения):



Мое сообщение к коммиту:



А что у нас теперь в истории?



Хорошо, это было весело. Я сделал несколько изменений и каждый раз, сделав значимое изменение, я фиксировал его в репозитории.

Я знаю, вы сейчас думаете: «ДЖОЭЛЬ, ВСЕ ЭТО ВЫГЛЯДИТ ПУСТОЙ ТРАТОЙ ВРЕМЕНИ». К чему вся эта катавасия с коммитами?

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

Для начала: скажем, вы сделали большую ошибку в процессе редактирования.



А затем, боже ж мой, в дополнение ко всему вы удалили пару очень важных файлов.



Во времена, когда не было Mercurial, это все могло бы стать неплохим поводом для похода к системному администратору. Там, со слезами на глазах, вы бы задали ему пронзительно грустный вопрос: «Почему система резервного копирования „временно“ не работает все последние восемь месяцев».

Системный администратор, которого все зовут Тако, слишком скромен и не обедает с остальной командой. В тех редких случаях, когда он не сидит в своем кресле на колесиках, можно увидеть треугольное пятно цвета сальсы там, где падали, пролетев между ног, капли от его мексиканских закусок. Эти капли гарантируют, что никто не возьмет его кресло, хотя это одно из превосходных кресел от Herman Miller, купленных учредителями компании для себя любимых, а не обычное бюджетное офисное нечто, из-за которого у всех болят спины.

В любом случае, резервной копии нет, ага.

Благодаря Mercurial, если вам не нравится то, что вы сделали, вы можете выполнить удобную команду hg revert, которая немедленно вернет ваш каталог к виду, в котором он был в момент последнего коммита.



hg revert
возвращает измененные файлы к зафиксированному в репозитории виду.


Я использовал аргумент --all, потому что хотел вернуть все файлы к прежнему состоянию.

Таким образом, когда вы работаете над исходным кодом, используя Mercurial, вы:
  1. Делаете изменения
  2. Оцениваете, подходят ли они
  3. Если подходят, то выполняете commit
  4. Если не подходят, то выполняете revert
  5. GOTO 1


(Я знаю. Пользуюсь командной строкой, в Windows, да еще и оператором GOTO — я самый стрёмный программер из всех, когда-либо живших.)

Со временем вы можете забыть, на чем остановились и что поменяли с момента прошлого коммита. Mercurial отслеживает все это для вас. Все что вам нужно, это выполнить hg status и Mercurial даст вам список измененных файлов.

hg status
отображает список измененных файлов.


Предположим, я создал один файл, отредактировал другой и удалил третий.



hg status отображает список измененных файлов, добавляя значок в начале каждой строки. Этот значок сообщает о том, что же произошло. «M» означаете «Modified» — файл был изменен. "!" означает отсутствие — файл должен быть здесь, но куда-то делся. "?" означает что, состояние не определено — Mercurial ничего не знает про этот файл. Пока не знает.

Давайте разбираться с изменениями поочередно. Вот что поменялось в файле a.txt? Вы ведь можете забыть, что изменили. Чёрт, да я едва помню что я обычно ем на завтрак. А особенно внушает опасения то, что это всегда хрустящие колечки CHEERIOS. В любом случае, a.txt изменен. Что поменялось?

А есть команда для этого: hg diff сообщит вам в точности, что произошло с файлом с прошлого коммита.

hg diff
показывает, что изменилось в файле.




Формат результата немного непонятный, но самое важное, что вы можете видеть строки, начинающиеся с минуса (это то, что было удалено), и строки, начинающиеся с плюса (это то, что добавлено). Таким образом, вы можете видеть, что «Normal people» было заменено на «Civilians».

Теперь про тот пропавший файл favicon.ico. Как уже было сказано, если вы на самом деле не планировали его удалять, то можете выполнить команду hg revert для восстановления. Но, предположим, что вы на самом деле хотели его удалить. При каждом удалении (или добавлении) файла вы обязаны сообщить об этом событии Mercurial.

hg remove
помечает файлы как запланированные для удаления из репозитория. Файлы на диске не будут удалены до тех пор, пока вы не зафиксируете изменения.




«R» означает «Removed», то есть, помечен для удаления. Во время следующего коммита Mercurial удалит этот файл. (История для этого файла сохранится в репозитории, так что, конечно, мы всегда сможем получить его назад.) И, наконец, нужно добавить этот новый файл b.txt:



«A» означает «Added», то есть, помечен для добавления. Заметили, что я разленился писать hg status каждый раз? Для Mercurial достаточно минимального набора букв, однозначно определяющего команду, а на st начинается только одна команда.

Разобравшись с вопросиками и восклицательными знаками, я могу продолжить и внести изменения:



На что еще стоит обратить внимание в выводе hg log: строка changeset отображает номер каждого коммита. На самом деле даже два номера: короткий удобный вроде «0» для первой ревизии и длинный непонятный шестнадцатеричный, на который вы можете пока не обращать внимания.

Запомните, что Mercurial хранит в репозитории достаточно информации для воссоздания любой версии любого файла.

Прежде всего, при помощи простой команды hg cat вы можете вывести содержимое любой версии любого файла в консоль. К примеру, вот как увидеть, что сейчас находится в файле a.txt:



hg cat
отображает содержимое любого файла для любой ревизии.


Для того чтобы увидеть как файл выглядел раньше, я могу просто указать нужный номер набора изменений (changeset из лога) при помощи аргумента -r («revision», то есть ревизия):



Если у файла сложное содержимое или большая длина, а изменился он лишь немного, то я могу использовать команду hg diff с аргументом r для вывода разницы между двумя ревизиями. К примеру, вот как посмотреть разницу между ревизиями 0 и 1:



И наконец,- надеюсь, что вы еще не свалились от усталости,- прежде чем закончить эту часть, я хочу показать вам еще одну маленькую фишку: при помощи команды hg update вы можете перемещаться вперед и назад ко времени создания любой ревизии. Ну, по сути в будущее вы перемещаться не сможете, хотя это было бы супер круто, да. Вы, имея всего четыре ревизии, смогли бы выполнить hg update -r 103994 и получить реально крутую версию ваших исходников. С гравицапой и прочими футуристическими штучками. Но, конечно, это невозможно.

Что на самом деле возможно, так это вернуться к любой ревизии. Следите за руками:



hg update
приводит рабочий каталог к состоянию, как у заданной ревизии.


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

Проверь себя


Отлично! Эта часть закончена. Вот все, что вы должны уметь делать на данный момент:
  1. Создать репозиторий
  2. Добавить или удалить файлы из репозитория
  3. После внесения изменений просмотреть, что было сделано, а затем
  4. … зафиксировать изменения, если они вам нравятся
  5. … или откатить изменения, если не нравятся
  6. Просмотреть предыдущие версии файлов или привести рабочий каталог к состоянию как у некоторой ревизии.


Продолжение здесь:
Hg Init: Часть 3. Привыкаем работать в команде
Перевод: Joel Spolsky
Сергей Бобровский @Bobrovsky
карма
145,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (66)

  • +1
    Есть для git'a & Mercurial'a нечто наподобии TortoiseSVN? Можно ли подключать кастомный diff viewer & merge editor?
    • +6
      Есть: TortoiseHg, TortoiseGit.

      в TortoiseHg точно можно подключить кастомный diff viewer.
      • +4
        Более того, TortoiseHG даже работающий. И сильно упрощает (для меня как виндузятника) процесс ежедневный процесс работы. Особенно радуют иконки у файлов в Проводнике. Точно такие же, как у TortoiseSVN! :)

        Для TortoiseGIT придется *отдельно* скачать дистрибутив с прекомпилированным git-ом. А потом *как-то* его подключить к git-у.

        Вот из-за такого недружественного интерфейса я и остановился на TortoiseHG, который просто работает. :)
        • 0
          Вы не оправдываете свой ник ;)
          • +2
            К сожалению выбор корпоративногоо стандарта не в моей компетенции. А дома я труЪ ;)
    • 0
      mercurial.selenic.com/wiki/MergeProgram

      Я помучал под винду парочку, но ничего лучше KDiff3 не нашел.
      Внимание, вместе TortoiseHg мне отгрузили старый kdiff3.
      • 0
        По мне так Araxis Merge самый удобный инструмент. Правда, платный.
      • 0
        Мне TortoiseMerge больше всех нравится — позволяет сразу править отправляемый код во время коммита.
        • 0
          Мне кажется, это плохая идея :)
          • 0
            В общем — да.
            Но иногда в коммит норовят затисаться косметические правки типа удаления пробелов или переноса строк.
            Или отладочные строки, которые забыли удалить, типа вывода значения в дебаг, или закомментированный код.
      • +1
        Из бесплатных — лучше, чем DiffMerge (а смотрел много чего), вряд ли можно найти. Это не просто сравнивалка текста — она понимает контекст (C++/C#/Java) и умеет разрешать конфликты там, где SVN мучается изжогой. И, разумеется, можно править на лету, откатывать изменения поблочно, и т.д.

        • 0
          Я последнее время на CodeCompare переключился.

          Жаль что DiffMerge не обновляется. Юникод бы хотя бы допилили…
    • –2
      1) есть.
      2) можно.
    • 0
      наподобие
    • 0
      TortoiseGIT это ок, т.к. по сути это отрихтованный TortoiseSVN.

      TortoiseHG не ок, т.к. это собранный из разных кусков аналог. Со своим (gtk'шным вроде бы) гуи и т.д.
      • 0
        TortoiseHG не ок
        да плевать. главное, что оно 1) есть под Linux и 2) умеет коммитить файло кусками, что позволяет не использовать record extension и CLI
  • 0
    Отлично! Ждал второго перевода.
  • +6
    Как раз недавно мигрировал с SVN. Колебался между git и hg.

    Сначала выбрал git, и TortoiseGit мне понравился, но всё было более-менее хорошо, пока я не стал поднимать общий репозиторий. Оказалось, что поднять закрытый сервер git — это очень нетривиально, потратив несколько часов, я сдался. Больше всего в git бесит неинформативность сообщений об ошибках. Моё резюме: git только для opensource-анархии.

    Решился пожить с Mercurial и обрёл счастье: hg всегда сообщает, что именно не так, и что можно с этим сделать. К тому же механизм ветвлений гораздо прозрачнее. TortoiseHg сильно отличается от идеального TortoiseSVN, но обладает собственной логикой и работает надёжно. Я не сразу понял, что «branch» — понятие сугубо виртуальное, что все «бранчи» хранятся в одном и том же репозитории, и между ними можно легко и быстро переключаться, а Repository Browser позволяет наглядно видеть, что, когда с чем было смешано (merged).

    Ещё я пробовал Bazaar, но он нестабилен в развитии и очень уж самобытен. Хотя изначально нравился мне больше всех. Но Hg победил его простотой ветвления (о ветвлении под SVN я даже не знал — там это pain).

    В общем, рекомендую Mercurial :-)
    • 0
      И да, Спольски я давно читаю и уважаю, поэтому был рад при изучении Mercurial обнаружить hginit.com/ — ресурс очень помог освоить новые для меня подходы к контролю версий. Так что спасибо автору топика за востребованный перевод.
    • +5
      Моё резюме: git только для opensource-анархии.
      Ну оно просто умеет мергать сразу пачку веток, поэтому в ядре Linux без него никак.
      Сейчас в топик придут адепты Git и объяснят, что кактус принято есть левой рукой (желательно чужой, желательно свежей), загримировавшись под Джокера верхом на одноглазой гигантской крысе пёстрой масти в ошейнике из сплава 10 редкоземельных элементов и желательно нестабильного изотопа тория, напевая гимн СССР в тональности ля-диез минор вы его неправильно готовите.
      • 0
        > Ну оно просто умеет мергать сразу пачку веток

        Это как? Другие разве не?
        • –1
          За другие не скажу, но конкретно mercurial умеет мергать только две «головы» за раз. Соответственно, если
          1) в проекте 200 контрибьюторов, и
          2) каждый из них сделал по коммиту, не оглядываясь на коллег,
          то перед выпиныванием обновок им всем придётся сделать 200 merge commits (в сумме, не каждому — на лицо выйдет по одному-два). Впрочем, возможны и другие варианты (rebase/transplant, кажется; или отдельный репозиторий для сборки релиза, в который обновки выкладываются по hg unbundle — я тут не особо копенгаген).
          • 0
            Невероятная ситуация. Это если между ними нет никакой координации и нет единого центрального репозитория для обмена кодом.
            Решается всё очень просто: каждый делает pull + push + pull (контрольный) в центральный репозиторий — и всё обновлено.
            Две «головы» — это только для рабочей копии, а веток при этом может быть сколько угодно в одном репозитории. То есть если человек создал себе ветку и выложил её в общий репо, то я её также вытяну без смешивания, могу в неё «заглянуть», а потом вернутся в свою или главную ветку и продолжить работу. А когда пришла пора влить ветку в главную линию разработки в эту самую ветку тягаются изменения из главной, а потом обратно — и всё слито.
            Разве не? )
            • 0
              всё так. естественно, это синтетический пример и такого в жизни не бывает.

              я имел в виду что после вот такого
              for ((i = 0; i < 5; i++)); do touch $i ; hg ci -A -m "commit $i"; hg up -r 0; done
              в случае с mercurial понадобится 4 merge commits, тогда как в случае с git — 1. Всё.
              • +1
                Проверил, действительно ))
                Правда, хватило трёх merge-коммитов:

                [root test]# hg init .
                [root test]# for ((i = 0; i < 5; i++)); do touch $i ; hg ci -A -m "commit $i" -u me; hg up -r 0; done
                adding 0
                0 files updated, 0 files merged, 0 files removed, 0 files unresolved
                adding 1
                0 files updated, 0 files merged, 1 files removed, 0 files unresolved
                adding 2
                created new head
                0 files updated, 0 files merged, 1 files removed, 0 files unresolved
                adding 3
                created new head
                0 files updated, 0 files merged, 1 files removed, 0 files unresolved
                adding 4
                created new head
                0 files updated, 0 files merged, 1 files removed, 0 files unresolved

                [root test]# hg merge
                abort: branch 'default' has 4 heads - please merge with an explicit rev
                (run 'hg heads .' to see heads)
                [root test]# hg merge -r 1
                1 files updated, 0 files merged, 0 files removed, 0 files unresolved
                (branch merge, don't forget to commit)
                [root test]# hg merge -r 2
                abort: outstanding uncommitted merges
                [root test]# hg ci -m "Merge" -u me
                [root test]# hg merge -r 2
                1 files updated, 0 files merged, 0 files removed, 0 files unresolved
                (branch merge, don't forget to commit)
                [root test]# hg ci -m "Merge" -u me
                [root test]# hg merge -r 3
                1 files updated, 0 files merged, 0 files removed, 0 files unresolved
                (branch merge, don't forget to commit)
                [root test]# hg ci -m "Merge" -u me
                [root test]# hg heads
                changeset: 7:7730558ebc8b
                tag: tip
                parent: 6:f7693b67ce1f
                parent: 3:e07e55ac1d22
                user: me
                date: Tue Nov 23 16:36:20 2010 +0300
                summary: Merge


                Но вообще-то я считаю эту логику более верной и целостной — вливать изменения по одному, а не скопом. Так легче отследить природу вещей и получить понятное дерево веток.
                • +2
                  хватило трёх merge-коммитов
                  А. Ну да, ступил.
                  кстати это вы зря под рутом сниппеты от незнакомых людей запускаете ;)
                  Но вообще-то я считаю эту логику более верной и целостной — вливать изменения по одному, а не скопом. Так легче отследить природу вещей и получить понятное дерево веток.
                  согласен
                  • +1
                    > кстати это вы зря под рутом сниппеты от незнакомых людей запускаете ;)

                    Ага: «не читайте Хабр под рутом» ))
                    Ну да у меня препарсинг в голове был успешно пройден )
              • 0
                Вас спасёт rebase

                p,s.
                Да, я некрофаг -))
    • 0
      > Оказалось, что поднять закрытый сервер git — это очень нетривиально, потратив несколько часов, я сдался.
      Расскажите, с Hg это оказалось проще?

      Для Git есть gitk и очень удобный кроссплатформенный SmartGit, они тоже показывают деревья.
      • 0
        > Расскажите, с Hg это оказалось проще?

        Да, намного. Если ошибаешься, то Hg пишет нормальный текст ошибки в лог с указанием способа её исправить.
        Всё быстро настроил через apache+hgweb.cgi.

        С git так и не смог разобраться — просто не работает и всё, и никаких тебе ошибок ни в одном логе. Плясал с бубном долго, потом плюнул. В форумах многие сокрушаются о трудностях в настройке авторизованного доступа к git, но воз и ныне там.

        У tortoisegit, кстати, тоже не всё хорошо, когда требуется вводить логины/пароли при доступе, а вот у tortoisehg всё с этим замечательно. И тут тоже hg гораздо более толково отвечает в случае ошибок.
        • 0
          >> В форумах многие сокрушаются о трудностях в настройке авторизованного доступа к git, но воз и ныне там

          Можно использовать тот же прием, что и в SVN с протоколом svn+ssh:
          svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks
          • 0
            Давать человеку доступ к серверу по SSH только ради работы с репозиторием — это бред по-моему.
            • 0
              Достаточно одной учётки с шеллом hg-ssh для всех пользователей. Или mercurial-server
        • 0
          По поводу web-доступа. В TortoiseHG есть встроенный мини-сервер. Для домашних нужд, так сказать. Заводится нажатием на одну кнопку. Ничего стороннего не надо.
          • 0
            Если уже работает Apache, зачем плодить сущности?
            А так да — удобно, некоторые разработчики, говорят, по локалке или через интернет с помощью этого встроенного сервера обмениваются обновлениями между репозиториями )
            • 0
              Вот только у этого сервера есть одна серьезная проблема — он не поддерживает аутентификацию пользователей.
              То есть чтение и запись в репозиторий можно либо разрешить либо запретить ВСЕМ пользователям. Так что за пределами локальной сети он не применим, да и в локальной довольно небезопасен…
            • 0
              Это да. Но *обычно* на венде нету Апача :)
              • 0
                Зато обычно на винде есть IIS.
                Лично у меня под ним поставилось гораздо проще чем под апачем и убунтой. (хотя, может быть это потому что винда мне привычней)
                • 0
                  Я не заморачивался. Встроенного сервера мне вполне хватило.
      • 0
        Я поднял всё это хозяйство очень просто и быстро даже на обыкновенном shared-хостинге. Это просто как:

        easy_install mercurial && vim hgwebdir.cgi && vim hgweb.config && vim .htaccess

        Для аутентификации использовался уже существующий .htpasswd.
    • 0
      Не нравится в hgweb.cgi, что можно настроить права на push, но нельзя на hg pull. Т. е. если на сервере несколько репозиториев с аутентификацией по http(s), то все будут иметь доступ на чтение всех репов.
      • 0
        Я, к слову, предпочитаю mercurial-server. Есть в репозиториях, легко настраивается, очень гибкий. Крайне доволен.
      • 0
        Как верно отметил develop7, для Mercurial вообще есть много вариантов.

        Что же касается связки с apache, то ничто не мешает вам настроить столько разных hgweb.cgi (со своим конфигом, набором репозиториев и правами доступа) по разным URL, сколько вам нужно. При этом например можно использовать один и тот же или разные .htpasswd, а также для каждого репозитория отдельно настраиваются права доступа в hgrc.
        • +1
          Лень мешает… сейчас мне для создания репа надо сделать mkdir, hg init, прописать allow_push и всё. Настраивать всё практически заново намного дольше.

          Ларчик проще открывался: есть опция allow_read в hgrc, в доках о ней почему-то редко упоминают (не всегда она была видимо). У меня работает. Дока: www.selenic.com/mercurial/hgrc.5.html
          • 0
            Точно.

            И вот пусть теперь апологеты git укажут, как нужно плясать, чтобы сделать такую же конфигурацию (с частично запрещённым pull и частично разрешённым push) под git + apache )
  • +1
    Это все конечно хорошо и наверно даже кому-то полезно, но что бы хотелось так это как работать с Hg в реальных проектах — как организовать множество репозиториев для отдельных частей проекта, как организовать деплой на продакшн, как организовать цикл разработки и так далее

    А базовая версионность у меня в IDE есть :)
  • 0
    Я правильно понял, что по умолчанию Hg при коммите добавляет все изменённые файлы? Имхо не очень очевидно и удобно.
    • +3
      По умолчанию он предлагает сохранить все изменения в уже добавленных в репозиторий файлах. Неизвестные ему файлы он отмечает как неизвестные, их можно добавить в коммит.
    • +1
      В общем-то правильно поняли.
      Но речь идет об умолчаниях, при работе из командной строки.
      В реальности же вы будете использовать плагины к вашей IDE либо tortoiseHG и там что выберете то и добавит.
    • +2
      Можно сделать hg commit файл/каталог, чтобы закомитить только файл/каталог.
      • 0
        Я не очень знаком с тем, как остальные пользуются VCS, но я как-то в Git не привык делать stash, так что бывает после некоторого количества изменений открываю gui, выбираю нужные часть/файлы и делаю отдельные коммиты. В Hg, получается, придётся делать revent, потом коммит первого, а потом остаток. имхо, это не очень последовательно, но это скорее дело вкуса.
        • 0
          ну я в hgtk (tortoisehg) аналогично выбираю какие файлы/куски файлов коммитить. и опять-таки — команде hg commit можно явно сказать «коммитим это, это, это и вот эти два каталога».
    • 0
      Более того, из нескольких изменений в одном файле можно комитить только некоторые, а остальные потом «сбросить», сделав revert.
      • 0
        Если бы он этого не умел, думаю многие бы выбрали Git ;-)
  • +2
    прочитал статью — пока никаких отличий от svn, буду ждать описания ветвлений
    • +2
      На самом деле это кусочки одного большого документа, который обретёт смысл тогда, когда будет доступен целиком.
    • +1
      Первая часть, кстати, более информативна, на мой взгляд. А чтобы врубиться в то, как работают ветки, достаточно взять hg и попробовать, прочитав официальный man с вики-страницы проекта — mercurial.selenic.com/wiki/UnderstandingMercurial
    • +1
      Видимо не очень внимательно читал :)
      Одно из главных отличий — для использования всех преимуществ системы контроля версий не нужен отдельный сервер. Можно локально на диске создать репозиторий и работать. Или при работе с удаленным репозиторием, при потере связи с сервером можно спокойно работать со своим локальным репозиторием, а когда связь появится, синхронизироваться с удаленным.

      В жизни встречается немало ситуаций когда это критично.
    • 0
      Одно важное для меня отличие уже есть: Если работаешь один, то репозиторий создаётся прямо в каталоге проекта — не надо думать где его разместить, а потом вспоминать куда засунул, если надо перенести на другую машину.
  • 0
    Глупый вопрос, а почему hg? svn для subversion — логика прослеживается, про git и говорить нечего, а тут…

    А вообще спасибо и автору, и переводчику. В официальных доках всё как-то запутано, имхо
    • 0
      первая картинка намекает
      • 0
        Ну, hydrargyrum — ртуть, это я с школы помню… А причем меркурианский?
        • 0
          упс, меркурианский — mercurian, а не mercurial — ртутный :)
    • 0
      Мне тоже не нравится эта путаница.
      Пишите hg, называйте «эйчджи» или «хаге», и все вас поймут всё равно ))

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