Распределённая система контроля версий Mercurial обновлена до версии 4.8


Оглавление (нажмите, чтобы открыть):

Блог Илхома Назарова

Задача проектного менеджера и коммерческой разработки как таковой — ставить конкретные цели и отслеживать этапы выполнения работ.

Для этого в производственный процесс принято внедрять ежедневные митинги, таск трекеры и системы контроля версий (СКВ или VCS — Version Control System), которые мы рассматриваем как инструменты для управления проектами.

Выбор СКВ лежит на плечах технического директора, тимлидов или воли случая (“так исторически сложилось”). Вопросы о преимуществах или недостатках конкретных систем вызывают священные войны в среде разработчиков, однако, наc они итересуют только в контексте организации работы над проектом.

Популярные решения

По опыту 9 из 10 команд разработки используют Git, хотя рейтинг Tagline говорит о меньшей его популярности.

После Git с большим отрывом идет SVN (Subversion) и Mercurial.

Синтаксис Git сложнее в изучении, однако, по отзывам программистов он функциональнее. Очков гиту добавили и популярные ресурсы для хранения репозиториев на всевозможных языках: GitHub и BitBucket.

Долю на рынке, сопоставимую с массой электрона, занимают осталные системы : CVS (Concurrent Versions System), Team Foundation Server, Bazaar, Darcs итд.

Все системы контроля версий по сути решают 4 задачи

Доступ к коду. Исходники кода хранятся в удаленном репозитории (хранилище данных), куда обращаются разработчики, чтобы забрать актуальную версию файлов или внести изменения. Так выстраивается командная разработка.

Логирование изменений в коде. Отслеживание коммитов (внесений изменений в код), помогает найти кто, что и когда менял, решить конфликты при модифицировании одних и тех же файлов, откатиться на любое предыдущее состояние.

Ветвление разработки. Программисты параллельно ведут разработку нового функционала в отдельных ветках, не затрагивая работоспособности старого.

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

Организация процесса разработки

Вам, как менеджеру проекта, стоит обратить внимание:

  1. Принят ли у разработчиков единый шаблон оформления комментариев к коммитам (commit message), из которых понятно, что делает коммит и зачем.
  1. Настроена ли привязка коммитов к конкретным задачам из таск трекера (traceability) для трассировки бизнес требований.
    В Mercurial это работает из коробки, а вот, например, в Git это обычно решают с помощью хука, который не дает ничего закоммитить без метки таска, а-ля “PROJECT-JIRA_ISSUE_NUMBER”
  1. Делают ли разработчики ежедневный пуш (выгрузку коммитов) в центральный репозиторий или работают локально не отдавая написанный за день код вовне.

Последний вопрос не актуален, если разработчики используют на проекте SVN, так как это централизованная СКВ и весь код хранится на сервере.

Распределенные и централизованные подходы к хранению кода

Git и Mercurial — распределенные системы, SVN — централизованная.

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

При этом Git, в отличие от Mercurial, работает не только с локальными коммитами, но и с локальными ветками, которые можно вовсе не заливать в удаленный репозиторий.

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

C этой точки зрения, SVN лучше вписывается в модель коммерческой разработки, где мы ежедневно контролируем объем и качество выполненной работы.

При использовании Git или Mercurial проектному менеджеру необходимо установить правило ежедневных коммитов для разработчиков, это особенно критично для удаленных команд или аутсорсеров.

Как менеджеру освоить базовые функции Git

Вероятность столкнуться с использованием гита на проекте 90%, поэтому небольшая рекомендация для тех, кто собрался его изучить.

Короткий видеокурс Geekbrains для старта за 2 часа.
Официальная документация для дотошных.

На Mac Git по умолчанию вшит в штатную консоль. На Windows первым делом скачайте и установите сам Git.

С гитом работают через консоль или графический интерфейс (GUI).

Для задач IT-менеджера рациональнее использовать графический клиент. Лично я использую SourceTree, хотя не всем нравится продукция Atlassian.

unixforum.org

Форум для пользователей UNIX-подобных систем

  • Темы без ответов
  • Активные темы
  • Поиск
  • Статус форума

[ON] Выпуск распределённой системы управления версиями Mercurial 4.8

[ON] Выпуск распределённой системы управления версиями Mercurial 4.8

Сообщение rssbot » 05.11.2020 10:00

Доступен релиз распределённой системы управления версиями Mercurial 4.8. Код Mercurial написан на языке Python (требующие высокой производительности части оформлены в виде модулей на Си) и распространяется под лицензией GPLv2+. Среди проектов, использующих Mercurial, можно выделить следующие: Mozilla, OpenOffice.org, OpenSolaris, NetBeans, OpenJDK, Nginx, Xine и W3C.

Основные изменения:

  • Стабилизирована реализация шаблонов форматирования, которые можно применять для настройки формата вывода любых команд, в том числе для применения JSON и XML для вывода;
  • Реализовано расширение «closehead» для закрытия произвольных веток без выполнения операции checkout;
  • Добавлена новая настройка commands.resolve.mark-check для вывода предупреждения или ошибки при выполнении операции «—mark» при наличии конфликтующих файлов;
  • Добавлена новая настройка commands.resolve.confirm для подтверждения действий, выполняемых без указания имени файла;
  • В команду rebase добавлен флаг «—stop» для остановки прерванных операций без отбрасывания уже перенесённых изменений;
  • Предложено экспериментальное расширение absorb для «поглощения» рабочих изменений соответствующими наборами изменений;
  • Добавлено экспериментальное расширение fastannotate для ускорения операций аннотирования с использованием предварительно сформированного кэша. Расширение также предоставляет дополнительные опции, такие как «—deleted»;
  • В набор hgext добавлено расширение phabricator;
  • В файл конфигурации добавлена настройка http.timeout для определения таймаута;
  • Обеспечена автоматическая загрузка расширений для работы с текущим хранилищем (например, lfs);
  • Расширены правила автодополнения ввода команд hg для zsh;
  • Проведены оптимизации производительности.

Особенности Mercurial:

  • Быстродействие:
    • Высокая производительность работы с хранилищем, не зависящая от числа элементом в нём (O(1) revlog);
    • Компактное хранение данных в проиндексированном и сжатом виде;
    • Оптимизирован для эффективной работы с данными на жёстком диске;
    • Все изменения и файлы в репозитории дополнительно проиндексированы;
    • Для копирования данных по сети используется HTTPS и SSH, данные передаются в сжатом виде.

  • Масштабирование
    • Распределённая модель разработки позволяет участвовать в проекте неограниченному числу разработчиков;
    • Допускается произвольное слияние отдельных децентрализованных репозиториев, поддерживаемых отдельными разработчиками;
    • Объём репозитория, число файлов и зафиксированных изменений не отражается отрицательно на производительности;
    • При работе нет необходимости ждать освобождения блокировки.
  • Надёжность.
    • Для контроля целостности данных в репозитории используется SHA1 (запланирован переход на SHA256);
    • Хранилище реализовано в журнальном виде — данные не замещаются, а добавляются. Ведётся журнал транзакций;
    • Быстрый алгоритм проверки целостности репозитория;
    • Встроенные средства резервного копирования и проверки целостности;
  • Удобство использования.
    • Привычный CVS-подобный набор команд;
    • Наличие встроенной системы подсказки;
    • Интегрированный Web-интерфейс;
    • Большой выбор GUI-интерфейсов.
  • Лёгкость внедрения:
    • Поддержка платформ UNIX, macOS и Windows;
    • Средства, упрощающие миграцию с других систем управления исходными текстами;
    • Поддержка нескольких моделей организации репозитория: централизованная cvs-подобная, децентрализованная иерархическая и распределённая полуиерархическая;
    • Поддержка внешних обработчиков и дополнений.

Распределённая система контроля версий Mercurial обновлена до версии 4.8

сделал вторичный репозиторий на флэшке, утащил на работу (где день-два нечего делать — ждем смежников, а ssh наружу на мой репозиторий закрыт), покодил, да слил обратно.

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

9. evilbloodydemon , 06.07.2009 18:23
Pentero
не денется. но вариант с клоном удобнее.
10. Pentero , 07.07.2009 14:55
А можно ли сделать так чтобы для некоторых файлов проекта не велась история, но чтобы например их также можно было клонировать вместе с остальными файлами проекта? Причем эти файлы меняются, но отслеживать их изменение не надо.
11. dozen , 07.07.2009 15:30
Pentero
Причем эти файлы меняются, но отслеживать их изменение не надо.

то есть с одной стороны файл не в репозитории, а с другой — да? странного хочешь.

12. femidav , 07.07.2009 22:37
dozen
сделал вторичный репозиторий на флэшке, утащил на работу (где день-два нечего делать — ждем смежников, а ssh наружу на мой репозиторий закрыт), покодил, да слил обратно.
Принёс working copy на флешке, покодил, пришел домой, закоммитил.
13. Chippy2003 , 07.07.2009 23:26
femidav
Принёс working copy на флешке, покодил, пришел домой, закоммитил.
особенно хорошо коммитятся удаленные на работе файлы
14. dozen , 07.07.2009 23:39
femidav
Принёс working copy на флешке, покодил, пришел домой, закоммитил.

в смысле, скопировать весь рабочий каталог вместе с CVS-файлами и т.д.? хорошо. изменил на работе 20 файликов из 500. как копировать обратно, чтобы CVS не решила, что все файлы обновились? на флэшке-то даты обновления = дате копирования на оную . зачем оно мне, ручная работа? я лучше воспользуюсь специально для этого созданным тулом и буду иметь peace of mind.

15. Yak , 08.07.2009 08:37
femidav
Принёс working copy на флешке, покодил, пришел домой, закоммитил.
Не подходит во многих случаях:
Во-первых, настройки проектов могут быть разными на разных машинах (см, например, *.user — файлы VisualStudio)
Во-вторых, зачастую нужно закоммитить прямо «на работе».
По-итогу, я, например, таскаю прямо весь SVN-репозиторий (благо, домашние проекты не особо большие и флешка Voyager GT шустра). А для больших репозиториев нетрудно набросать скрипт, чтобы таскать не весь репозиторий, а только новые правки.
16. Dilon , 08.07.2009 10:41
dozen

Почему это?

17. ash of mind , 08.07.2009 10:47
Yak
По-итогу, я, например, таскаю прямо весь SVN-репозиторий (благо, домашние проекты не особо большие и флешка Voyager GT шустра)
Может, я чего-то недопонял — а веб-репозитории чем не устраивают? Дома поработал, закоммитил, на работе слил, снова работаешь. Разве что на природе вне зоны доступа GPRS они недоступны (но я, когда оказываюсь в таких местах, меньше всего думаю о работе).
18. Yak , 08.07.2009 12:08
ash of mind
Может, я чего-то недопонял — а веб-репозитории чем не устраивают?
Зависимостью от наличия доступного интернета, например.
Много нормальных надежных бесплатных веб-репозиториев для не-опенсурсных проектов?
19. ash of mind , 08.07.2009 12:25
Yak
я использую http://unfuddle.com/ вот уж с полгода, наверное — жалоб пока нет (правда, там svn, а не сабж)
20. Dilon , 08.07.2009 13:45
ash of mind
там еще и git есть
21. Yak , 08.07.2009 14:45
ash of mind
Спасибо за ссылку, буду иметь в виду.
22. dozen , 08.07.2009 16:46
Dilon

главное — не git! . Почему это?

Вокруг гита много нездоровой истерии. Возникает чувство брезгливости быть в одной группе с брызжущими слюной идолопоклонниками.

Seriously, rabid advocacy by Git fans is making the world a lousy place to live. Git is really cool, but it is not the right tool for every situation.

In their defense, let’s acknowledge that the apple didn’t fall far from the tree on this particular issue. When people begin exploring DVCS, often one of the first things they find is the video of Linus Torvalds and his 2007 presentation about Git. And what they find there is someone who doesn’t seem to get it.

Folks, Subversion is probably the most popular version control tool in the world right now. Almost everyone using a version control tool today is using one that is built on the Line model of history, and they’re using these tools successfully and productively. When someone refuses to acknowledge any validity in that model, they look clueless.

The Torvalds video has done plenty of damage. That kind of attitude is a big turn-off for people interested in what’s new in the world of version control.

So, my fellow admirers of Git, if you are trying to prevent people from using DVCS tools and make sure that they stay confined to their current niches, then keep up the good work.

But if you really want to help the world see the benefits of Git and similar tools, then start realizing that people were getting productive work done before they existed.
===

Добавление от 08.07.2009 16:46:

ash of mind
а веб-репозитории чем не устраивают?

доступ наружу закрыт.

23. Rubanetz Miroslav , 14.07.2009 13:13
dozen
может вы мне объясните прелесть dvcs в корп или личных проектах ? ( был зверски занят и конференцию не читал ).
из 3х заходов на рсдне я вынес выводы а)людям не хватает скорости б)там есть несколько плюшек, которые в svn/perforce поленились прикрутить. Пообещал себе посмотреть на tortoisegit, когда его доделают.

Пока были свои проекты сам делал скриптик на питоне который дампит и пакует репозиторий svn на флешку и соотв распаковывает. Работало быстро даже на P3-600 Главное понять что это только код написанный 1м человеком а не буст и все-все-все опенсорс исходники со всего мира .

В корпоративных так вообще непонятно. Есть центральные билды ( ++ как никак). Есть qa. Все вообще центральное. Кому надо dvcs ?
Наоборот при общем уровне когда малейший конфликт и мне надо его разруливать, то что svn заставляет людей мержиться при update мне на руку тк в этой ситуации они сами вынуждены решать конфликт. Как правило удаляют и по новой но работает. Зовут только в серьезных случаях.

24. evilbloodydemon , 14.07.2009 13:34
Rubanetz Miroslav
ну на рсдн некоторые думают переходить ли с VSS на CVS или еще подождать, так что это не показатель.

я думаю у вас некий ментальный блок. попробуйте подумать о dvcs в терминах svn

mercurial -> svn
локальный репозиторий -> рабочая копия
удаленный репозиторий -> сервер
push -> commit
pull -> update
commit -> нет аналога

то есть, коммит в представлении svn может быть разбит на несколько локальных коммитов. что позволяет разработчику фиксировать шаги решения некоторой задачи проекта. сделал — забрал из удаленного репозитория изменения, смержил (как раз то самое, что вам на руку), отдал свои.

25. dozen , 14.07.2009 15:13
Rubanetz Miroslav
может вы мне объясните прелесть dvcs в корп или личных проектах ?

В личных — я уже объяснил, возможность работать с репозиторием в environments, откуда прямой доступ к данному репозиторию закрыт. «Скриптик, пакующий на флешку» — это хак, я хаки не приемлю.

В корпоративных, как ни странно, тоже возможность работать в environments, откуда прямой доступ к главному репозиторию закрыт. Представь себе консалтера (меня) с лэптопом, выехавшего на площадку к клиенту. Часть кода, который я использую, принадлежит клиенту (его репозиторий), часть — консалтерской компании (стандартные либы типа логгинга, SQL-процедуры, либы интеграции со специфическими продуктами, . ). В сети консалтера недоступен репозиторий клиента, в сети клиента — репозиторий консалтера. В то же время, для обеспечения работы консалтерских либ у данного клиента часто приходится делать фиксы или расширения. Держать их некомиченными никуда — некомильфо, ибо может вестись одновременно несколько веток (стабильная и девелоперская как минимум). Идеально как раз иметь репозиторий DVCS на лэптопе. По факту же сейчас приходится или иметь репозиторий только на стороне консалтера (клиент недоволен), или задерживать коммиты, и чекаутить код несколько раз в разные проекты под разными ветками.

Все эти неудобства можно обойти. Как сказано выше, people were getting productive work done before they (DVCS) existed. Просто с DVCS это получается естественней. Правда, появляется необходимость следить за деревом (http://www.ericsink.com/entries/dvcs_dag_1.html) .

26. Rubanetz Miroslav , 14.07.2009 18:01
dozen
насчет хранения на лептопе 2х репозиториев при недоступности сетей это как бы это сказать с точки зрения секурности ППЦ. Только на секунду подумайте — доступ в сеть обеспечить не смогли а вынос самого ценного со всей историей так пожалуйста.
Скриптик пакующий на флешку — это бэкап репозитория. С ноутом это делать не надо. Удобство — 100 %. В случае ошибки просто берем нужный бекап и не нужно мучаться с инструментарием управления репозиториями. Для личного проекта нам ведь не нужно одновременно 2 репозитория, правда ?
В общем пока не убедили . Сплошная экзотика и извращения. В нормальной конторе с централизованным менеджментом и QA имхо это все dvcs будет встречено диким ржанием


27. dozen , 14.07.2009 18:58
Rubanetz Miroslav

с точки зрения секурности ППЦ. Только на секунду подумайте — доступ в сеть обеспечить не смогли а вынос самого ценного со всей историей так пожалуйста.

Не совсем понятны concerns. Контракторы и так с лэптопами бегают туда-сюда, ничего нового не добавляется.

Когда заказчик волнуется, он выдает десктопы. На десктопы репозиторий консалтера переносится так:

— (в сети консалтера) создали вторичный репозиторий на флешке
— (в сети заказчика) создали третичный репозиторий с флешки на десктоп
— при необходимости переноса изменений туда или обратно делаем push или pull на флешковом репозитории

Скриптик пакующий на флешку — это бэкап репозитория. С ноутом это делать не надо. Удобство — 100 %

Я пока не услышал, как потом нормально сливать изменения — по приносу оного обратно в сетку? Переписывать локальную копию целиком?

В нормальной конторе с централизованным менеджментом и QA имхо это все dvcs будет встречено диким ржанием

Странный вывод. Как DVCS несовместим с «централизованным» менеджментом? Чем с точки зрения управления версиями репозиторий DVCS отличается от ветки в SVN/CVS? Ничем. Только физический DCVS-репозиторий может содержать несколько веток одновременно, а для SVN/CVS я вынужден чекаутить тот же проект несколько раз — из разных брэнчей.

Добавление от 14.07.2009 18:58:

В общем пока не убедили

Такой задачи не стояло.

28. Rubanetz Miroslav , 14.07.2009 19:12
dozen
Я пока не услышал, как потом нормально сливать изменения — по приносу оного обратно в сетку? Переписывать локальную копию целиком?
Для проекта с 1м программистом это не вопрос. Тут просто нет параллельных изменений. Для контор носить репозитории на флешках вроде никто не предлагал

Чем с точки зрения управления версиями репозиторий DVCS отличается от ветки в SVN/CVS? Ничем
Ну так с такой точки зрения «зачем dvcs ? ветки мы и так можем делать сколько хотим». В общем странное оно. Пока не понятно как извлечь выгоду буду использовать что привык. А в консалтеры мне еще рано

29. dozen , 14.07.2009 19:16
Rubanetz Miroslav

Для проекта с 1м программистом это не вопрос.

Даже для личного пользования — как таки сливать будешь?

Ну так с такой точки зрения «зачем dvcs ? ветки мы и так можем делать сколько хотим».

DVCS не про ветки, а про непривязку к центральному репозиторию, что в определенных условиях есть плюс. В определенных, но далеко не во всех.

30. femidav , 15.07.2009 00:07
Фактически преимущество DVCS свелось к local/delayed commits. Вот только эта фича не имеет непосредственного отношения к букве D в DVCS. D значит наличие графа репозиторий, при отсутствии центрального. А local/delayed commits можно наверно и к svn прикрутить.
31. Rubanetz Miroslav , 15.07.2009 00:13
evilbloodydemon
сорри не заметил сообщения. На рсдн как раз активно агитируют переходить и я у них пытался выпытать зачем.

dozen
Даже для личного пользования — как таки сливать будешь?
есстественно я не буду делать параллельных вселенных. Уходя из места А его репозиторий теряет актуальность и может рассматриваться как бекап не более. Те снос репозитория и подъем с флешки это как утром почитать почту Разумеется если я 1 на проекте и 100% уверен в том что делаю.

all
Меня в dvcs беспокоит то что у «тихих» разработчиков появится возможность жить в параллельной реальности и тихо фигачить себе код игнорируя остальных. Смысла в их параллельной реальности никакого тк чтобы привлечь внимание QA нужно интегрироваться, а они затянув о последнего потом придут ко мне с «ты ж у нас тут. смержишь как нибудь».
И второй вопрос — плюшки «где плюшки dvcs?» Переходя с cvs на svn я получил массу плюшек. Такого прыжка не видно

32. evilbloodydemon , 15.07.2009 08:37
femidav
А local/delayed commits можно наверно и к svn прикрутить.
более того, в svn 2.0 они и будут. и аналог меркуриаловского revlog’а в качестве хранилища.

но только в svn коммиты все равно будут создавать линейную историю. а mercurial создает нелинейную, то есть ветки создаются автоматически. а раз так, то работа с ними отлажена по самое нехочу. то есть мердж выглядит вот так:

hg merge
hg commit

всё. давайте-ка вспомним, как это делается в svn?

33. femidav , 15.07.2009 15:24
evilbloodydemon
а mercurial создает нелинейную
Это нафиг не нужно.
34. evilbloodydemon , 15.07.2009 15:54
femidav
Это нафиг не нужно.

сильный аргумент. это интересно же почему?

35. femidav , 15.07.2009 16:02
evilbloodydemon
более того, в svn 2.0 они и будут
Откуда это-то взялось?
36. evilbloodydemon , 15.07.2009 16:50
femidav

отсюда (http://subversion.tigris.org/roadmap.html)
hybrid distributed/centralized VC model

37. femidav , 15.07.2009 16:57
это ещё неизвестно когда будет, и будет ли вообще.
38. dozen , 16.07.2009 07:10
femidav
Это нафиг не нужно

брэнчи тоже не нужны. да и вообще version control не нужен. только путает.

39. femidav , 16.07.2009 10:02
dozen
Ну хорошо, какую проблему решает нелинейная история?
40. zzf , 16.07.2009 11:31
femidav
Ну хорошо, какую проблему решает нелинейная история?

Например, такую:
Ты взял последнюю версию проекта, исправил кучу исходников и хочешь зачекинить. Но в момент чекина обнаруживается, что кто-то уже вчекинил то, что менял ты.

Вроде бы это и не проблема, т.к. можно просто обновиться в текущую рабочую копию, что обычно и делается.

Ты обновляешься и где теперь твоя последняя исправленная версия? Правильно — нигде. Вместо неё некая новая версия с автомержами от сабвершена. Хорошо, если нет неразрешённых конфликтов и не появилось противоречий в архитектуре. А если наоборот?

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

41. Chippy2003 , 16.07.2009 11:36
zzf
Так вот, меркуриал позволяет отложить мерж на потом или отдать эту задачу другому члену команды и заняться более выжными на данный момент делами, а сабвершн просто принуждает тебя разрулить все конфликты именно сейчас.
Не догоняю, в чем отличие от branch ?
42. Yak , 16.07.2009 12:34
Chippy2003
Не догоняю, в чем отличие от branch ?
Дык, это и есть автоматический микробранч. SVN тоже на самом деле «позволяет отложить мерж на потом или отдать эту задачу другому члену команды и заняться более выжными на данный момент делами», только для этого нужно поработать ручками.
43. Rubanetz Miroslav , 16.07.2009 12:41
zzf
Так вот, меркуриал позволяет отложить мерж на потом или отдать эту задачу другому члену команды и заняться более выжными на данный момент делами, а сабвершн просто принуждает тебя разрулить все конфликты именно сейчас

И это разруливание сейчас решает тучу проблем.
Во первых оно провоцирует коммуникацию между разработчиками вносящими конфликтными изменения — это уменьшает
проблемы в архитектуре на порядки
Во вторых «другому члену команды» (как правила мне везет ) приходится делать 3way merges и при этом раскуривать трубку мира со всеми конфликтниками по очереди. А иногда помогают только групповые танцы с бубнами
Так что это именно та причина по которой я против dvcs в централизованной разработке одного продукта. Если много продуктов или супер много людей или еще что я готов смотреть на плюсы и минусы, но с 1м продуктом «Вот этого вот не надо» (с) старый анекдот.

44. femidav , 16.07.2009 13:14
Rubanetz Miroslav
И это разруливание сейчас решает тучу проблем.
+1. Чем дольше это откладывать, тем больше проблем. И вообще, перед коммитом всегда делается апдейт.

Так что это именно та причина по которой я против dvcs в централизованной разработке одного продукта.
+1.

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

45. zzf , 16.07.2009 14:00
Chippy2003
Не догоняю, в чем отличие от branch ?
Ты делаешь branch перед каждым чекином?

Добавление от 16.07.2009 14:07:

femidav
И это правильно и здорово. Первым делом баги, ну а фичи — потом.
Никто не говорит, что сначала фичи, а потом баги. У меркуриала принцип такой: сделал изменения, зафиксировал их в базе, работаешь над конфликтами. У сабвершена по другому: сделал изменения, обновился, работа над конфликтами, фиксация изменений. И пока ты не пофиксишь все конфликты, никто твоих изменений не увидит.

Добавление от 16.07.2009 14:16:

Rubanetz Miroslav
И это разруливание сейчас решает тучу проблем.
Во первых оно провоцирует коммуникацию между разработчиками вносящими конфликтными изменения — это уменьшает
проблемы в архитектуре на порядки

Ещё раз. Я не за то, чтобы отложить разруливание конфликтов. Как раз таки после чекина конфликты и рулятся. Но иногда бывают задачи и поважнее. А во-вторых, в сабвершне после изменения и апдейта ты теряешь первоначальную версию воркин-фолдера и её уже никак не вернуть назад. В меркуриале этого нет, т.к. сначала чекин, а потом мерж.


Добавление от 16.07.2009 14:19:

Rubanetz Miroslav
приходится делать 3way merges и при этом раскуривать трубку мира со всеми конфликтниками по очереди
Вот как раз эта проблема и решена в меркуриале на отлично. Там это даже не тема для головной боли.

46. Chippy2003 , 16.07.2009 14:26
zzf
Ты делаешь branch перед каждым чекином?
не, я не самоубийца, потом всю эту помойку мержить
47. Rubanetz Miroslav , 16.07.2009 14:35
zzf
И пока ты не пофиксишь все конфликты, никто твоих изменений не увидит.
и это правильно. Не хочешь чтобы все мучались — сиди в бранче.

Но иногда бывают задачи и поважнее.
ага ага.

А во-вторых, в сабвершне после изменения и апдейта ты теряешь первоначальную версию воркин-фолдера
жжоте. Вы не бинарниками в dvcs балуетесь ? Все остальное разруливается ручками очень просто при условии что вы коммитите только свои изменения и коммитите раз в 1-2 часа и Апдейты делаете регулярно (не реже 2х раз в день).

48. zzf , 16.07.2009 14:58
Rubanetz Miroslav
жжоте. Вы не бинарниками в dvcs балуетесь ? Все остальное разруливается ручками очень просто при условии что вы коммитите только свои изменения и коммитите раз в 1-2 часа и Апдейты делаете регулярно (не реже 2х раз в день).

Жгу. А теперь проделаем эксперимент. Бери последнюю версию любого проекта и делай изменения в одном файле. Теперь бери последнюю версию того-же проекта в другую рабочую папку, делай другие изменения в том же файле и строчке и чекинь. (Симулируем другого пользователя + конфликт) Теперь перед тем как чекинить из первоначальной рабочей копии, обновляемся. Что видим? Конфликт. А теперь задача: вернуть то, что было до апдейта, то есть, какая-то версия из базы плюс чисто твои изменения. Теперь пожги ты.

49. femidav , 16.07.2009 15:53
zzf
А теперь задача: вернуть то, что было до апдейта, то есть, какая-то версия из базы плюс чисто твои изменения
В чём смысл данной задачи?
50. Chippy2003 , 16.07.2009 16:03
один накоммитил пурги (переименовал все методы на китайские иероглифы), второй не коммитил 2 недели и проапдейтился не глядя
все нажитое непосильным трудом смешалось с пургой

другое дело, что восстановление своей рабочей копии главной проблемы все равно не решит

51. Rubanetz Miroslav , 16.07.2009 16:21
Chippy2003
не коммитил 2 недели и проапдейтился не глядя
жжоте. Я повторяю для нечитающих. Человек который не делает апдейт 2 раза в день — опасен для проекта. Такие вот тихие товарищи фигачат пол репозитория и уходят в отпуск не запустив регрешн.

zzf
теперь задача: вернуть то, что было до апдейта, то есть, какая-то версия из базы плюс чисто твои изменения.
открываем конфликт эдитор и как обычно. Ничего не пропало — у вас есть вся информация. Плюс вы знаете с каким Васей у вас будут проблемы с интеграцией. И знаете это до того как нафигачите гору кода которую будет жалко выбросить. Если вы не коммитились и тянули с фиксацией неделями то вам не стоит интегрироваться вообще нужно пробивать политическую правильность своего кода тк смержить его как правило уже тяжело.

Так что повторяю про svn коммит сразу как сделал шажок. Апдейт даже если не собираешься коммитить. Нужно знать что происходит в проекте а не спать на митингах.

резюме. То что dvcs облегчают «тихим» ребятам жизнь — мне сильно не нравится. Я тот кому придется эту . мержить потом. Так что меня не интересует что в какой то момент истории у когото все работало локально, а после обновления перестало и он не знает как исправить.

52. Chippy2003 , 16.07.2009 16:23
Rubanetz Miroslav
жжоте
там смайлик стоял

Добавление от 16.07.2009 16:27:

Rubanetz Miroslav
То что dvcs облегчают «тихим» ребятам жизнь — мне сильно не нравится. Я тот кому придется эту . мержить потом.
угу, как-то по этой ветке складывается впечатление о полной анархии, стремно

53. Rubanetz Miroslav , 16.07.2009 16:27
Chippy2003
я видел я также знаю такой случай как я описал. Потом месяц весь QA гонялся за тем товариЩщем. Они потом его боялись как черт ладана. Лучше так даже не шутить
54. evilbloodydemon , 16.07.2009 16:48
сдается мне что использование svn в описанных ситуациях с тихими васями — это решение административной проблемы техническими средствами, паллиатив.
но опять же, не вижу проблемы. достаточно запретить в основном репозитории создавать новые головы (heads) при пуше через pre-commit hook и никто не сможет залить несмерженные изменения.
55. dozen , 17.07.2009 17:12
Chippy2003

угу, как-то по этой ветке складывается впечатление о полной анархии, стремно

Как говорилось, анархия в головах, а не в туалетах.

В текущей CVS-основанной системе у моего последнего клиента разработчик забирает последнюю актуальную версию по тэгу, и делает брэнч. На протяжении всего процесса разработки или фикса он коммитит в свой брэнч. По окончании он делает merge обратно в актуальную ветку — и разрешает все конфликты сам.

Линейна ли такая история? Я сомневаюсь. Когда два и более девелоперов начинают задачи от одного тэга, получаются локальные нелинейные «распухания» истории. Потом, конечно, они сольются в линию, но в данный момент у каждого — свой брэнч.

Теперь один из них наткнулся на некую существенную проблему, для которой у него есть потенциальное решение, но его надо потестировать. Он создает подбрэнч (чтобы не терять уже накодированное). Дерево становится еще более нелинейным.

Как видно, нелинейность присутствует и в традиционных version control system, но никто сильно не пугается. Потому что существует понятная система «линеаризации» дерева веток. Система эта не столько техническая, сколько административная — это набор правил, что надо сделать до начала работы и после завершения оной. Такой же набор правил, разумеется, следует выработать и для DVCS.

56. femidav , 17.07.2009 17:40
dozen
По окончании он делает merge обратно в актуальную ветку — и разрешает все конфликты сам
А по ходу дела он что, совсем не merge не делает?
57. Chippy2003 , 17.07.2009 19:08
dozen
Потому что существует понятная система «линеаризации» дерева веток.
У меня сложилось впечатление, что здесь пропагандировалась не понятная система, а branch per random commit.

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

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

58. dozen , 17.07.2009 21:36
femidav
А по ходу дела он что, совсем не merge не делает?

Не делает. Зачем? Ну, специфика фреймворка в его (клиента) бизнес-процессах такова, что можно чужого кода не касаться.

Но дальше мне это видится как: Петь, там Маша накосячила и конфликт, возьми мой последний бранч, и Маша: Вась там Коля с похмелья чето накодил, возьми мой сегодняшний бранч или вчерашний, а Иван Иваныч потом все смерджит, честно.

Ну так это административная проблема, а не техническая. Я точно так же могу при SVN merge заявить, что изменения от Коли — они с похмелья, и сделать overwrite, и результат будет примерно тот же.

Вообще непонятно, к чему тут «возьми мой брэнч». Если девелоперы сами merge’ат в главную голову, то они сами и резолвят проблемы. Если мержит build master, то и в CVS/SVN конфликты разрешаются приглашением заинтересованных сторон. Копировать изменения между двумя ветками, ни одна из которых не одобрена к merge — это довольно опасная практика, IMHO, и от типа VC не зависит.

или административно за ними следить

Вопрос — а за какой VCS не надо административно следить?

59. Rubanetz Miroslav , 17.07.2009 23:11
dozen
ну понятно. Просто уровень ожиданий после того видео Линуса пару лет назад серьезно поболее чем «еще одна vcs». Как бы это объяснить — никого не прижимает ни скорость ни компактность репозитория ни супермержи каждый день. Кроме гигантов типа Линуса. Те это инструмент для немногих. Вот такое вот резюме.
60. dozen , 18.07.2009 00:14
Rubanetz Miroslav

Просто уровень ожиданий после того видео Линуса

после «того видео» осталось ощущение как после нечистоплотных salesmen, с напором впаривающих тебе что-то. Что существенно отложило момент, когда я сам решил посмотреть, что же такое DVCS.

Как бы это объяснить — никого не прижимает ни скорость ни компактность репозитория ни супермержи каждый день.

Меня частенько «прижимает» невозможность (нет VPN) или ужасающая медлительность (есть VPN) коммитов в корпоративный репозиторий. А не коммитить не могу — рефлекс.

61. femidav , 18.07.2009 08:31
dozen
Не делает. Зачем?
Чтоб его ветка от основной далеко не отклонялась, основная регулярно мержится в его собственную. Чтобы в конце не было неразрешимых проблем при обратном мерже.
62. Rubanetz Miroslav , 18.07.2009 12:25
dozen
вот свеженький пример (судя по всему веб разработчик) http://kolloid.livejournal.com/386267.html а вы говорите dvcs и следить.

Добавление от 18.07.2009 13:20:

зы. поспорил, поспорил, потом опять побеседовал с менеджментом на тему коммитов разработчиков и маразма с запросами на подтверждение каждого коммита для заказанных фич нерелизнутого софта и понял что придется таки переползать на связку «локальный dvcs — центральный svn»

63. ivanhoe , 20.07.2009 15:11
Из личной практики: DVCS полезны когда при коммите делается куча различных операций, в т.ч. автоматических — рассылка почтой, continious integration, etc. — чтобы разработчики не засирали это все своим потоком сознания, а коммитили что-то уже более-менее осмысленное.
64. Pentero , 21.07.2009 10:07
У меня практический вопрос: хочу при добавлении кучи новых файлов в репозитории исключить все которые имеют расширение class. Делаю так:

но файлы почему то все равно добавляются. Как правильно указать маску файлов?
И как все таки убрать некоторые файлы которые были добавлены но еще не закоммичены?

65. evilbloodydemon , 21.07.2009 10:37
Pentero
игнорируемые файлы настраиваются в файле .hginore в корне рабочей папки. для вашего случая он будет выглядеть так:

добавленные, но незакоммиченные файлы убираются так:


hg forget *.class

66. Pentero , 21.07.2009 12:15
evilbloodydemon
hg forget у меня не работает
67. evilbloodydemon , 21.07.2009 12:32
Pentero
что значит не работает? нет такой команды или она есть, но не убирает файлы? какая версия меркуриала?
68. Pentero , 21.07.2009 13:25
Версия Меркуриала 1.2.1, говорит что hg: unknown command ‘forget’
69. evilbloodydemon , 21.07.2009 14:30
Pentero
forget был снова добавлен в версии 1.3. это алиас для

hg remove -Af

70. Nemirov , 15.09.2009 10:34
Rubanetz Miroslav
понял что придется таки переползать на связку «локальный dvcs — центральный svn»
Аналогичный раздрай случился.
Как решали?
71. Rubanetz Miroslav , 15.09.2009 13:20
Nemirov
Как как — есть центральный svn а я держу у себя hg.
Пока не сделал нормальный способ (не в ручную) закидывать все изменения. Но мне и не особо хотелось светить всеми коммитами тк центральный используется для QA и beta customers.

Остальное работает. Могу рассказать если что.

С гитом не срослось под win, пока не понадобится что-то — смотреть не буду. Под линуксом наверное лучше гит — он там дома.

72. evilbloodydemon , 15.09.2009 13:37
Nemirov, Rubanetz Miroslav
http://bitbucket.org/durin42/hgsubversion/wiki/Home
http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
73. Rubanetz Miroslav , 15.09.2009 14:03
evilbloodydemon
жжошь. потестируй в полях — расскажешь.
74. Nemirov , 15.09.2009 14:28
Rubanetz Miroslav
Я правильно понял, что начиная с некого момента фактически вся история живет на hg, а в сабвершн периодически скидывается устаканенная версия, из которой собственно происходит сборка софта? В принципе вполне се вариант.

Добавление от 15.09.2009 14:32:

Rubanetz Miroslav
Под линуксом наверное лучше гит — он там дома.

У меня зоопарк — солярис с виндой и макосью до кучи, так что hg в самый раз

75. Rubanetz Miroslav , 15.09.2009 15:54
Nemirov
hg я бы не стал использовать для хранения крупных бинарей. Для hg на винде есть неплохой гуй в комплект к коммандной строке.
Я бы на зоопарке сильно подумал — что стабильнее git или hg ? У меня ведь шкурный интерес = пока вендовый гуй у гита не совсем работает мне он не интересен тк я с зоопарком работаю через ком строку. то есть там на зоопарке я ни мержей ни чего не делаю — только чекаут и run.
удачи
76. Pentero , 01.10.2009 09:07
Предположим что я сделал update на какую то из предыдущих ревизий. Как теперь с помощью команд mercurial узнать, какая ревизия у меня извлечена?
77. evilbloodydemon , 01.10.2009 10:00
Pentero

hg parents (http://mercurial.selenic.com/wiki/Parent)

78. Pentero , 26.10.2009 14:45
Как насчет ветвления в одном репозитории? Насколько я понимаю не возбраняется сделать несколько веток в одном репозитории и работать с ними по отдельности а потом сливать результаты?
Здесь я говорю именно о ветвлении в одном и том же репозитории, а не о создании клонов текущего репозитория и работе с ними.
79. evilbloodydemon , 26.10.2009 16:00
Pentero
Как насчет ветвления в одном репозитории?
а как же без него? если коммитят больше одного разработчика, то ветвление получится само собой. сознательно тоже можно и нужно делать ветки — feature branches к примеру, а потом мержить в основной ствол.

другое дело что у меркуриала как-то не очень с глобальной идентификацией временных веток. для локальной есть расширение bookmarks. но они не передаются при клонировании и обмене ревизиями.
есть только одна возможность — named branches, но в таком случае ревизия может принадлежать только одной ветке и имя ветки навсегда останется в истории.

80. Pentero , 26.10.2009 16:28
Хорошо, приведу вот такой упрощенный пример (для одного девелопера): есть репозиторий A, в котором ведется основная разработка, и в какой то момент создается (клонируется из A) репозиторий B в котором создаются некоторые доп.фишки, после чего сливаем снова ветку из B с веткой из A. Чем это лучше или хуже того, что просто бы создали отдельную ветку в репозитории A и работали бы с ней? Оверхед с клонированием с т.з. выделения места под еще один репозиторий вроде бы понятен.
81. Pentero , 12.11.2009 14:43
А как быть разработчику в винде? Интересуют нюансы кодировок: у меня файлы java в UTF8, редактор их понимает, зато комменты пишешь в 1251, поскольку hg почему то неправильно начинает показывать log если сохраняешь комментарии к коммитам в UTF8 и если кодировка cmd установлена тоже в UTF8.
Т.е. комменты для коммитов в 1251, а исходники в другой кодировке. Но насколько я понимаю проблемы могут возникнуть когда кто то будет работать в проекте из linux например, и у него комменты для коммитов будут в UTF8. Т.е. этот вопрос надо со всеми участниками обговаривать заранее.

82. dozen , 12.11.2009 15:45
Pentero
зато комменты пишешь в 1251

ну эта. обсуждали же уже по-английски надо писать комменты, по-английски!

83. Pentero , 13.11.2009 08:29
Удобно все таки иногда и по русски что то написать, а тут такое .
84. coldfire , 13.11.2009 08:47
Pentero
в Bazaar в винде с русским проблем нет, система очень похожа на Mercurial по простоте, но на мой взгляд удобней, больше фич, графический интерфейс тоже получше.

И кстати, идеально подходит тем кто хочет получить выгоду как от централизации, так и от распределенности. Можно коммитится локально и потом когда-нибудь push, а можно сразу на сервер, в svn стиле.

85. zzf , 13.11.2009 11:25
coldfire
в Bazaar . графический интерфейс тоже получше.

Графинтерфейс встроен в тулзу чтоли?

86. coldfire , 13.11.2009 13:12
zzf
нет, отдельная прибабаха как и в mercurial и svn.
87. Pentero , 16.11.2009 13:51
Я про Bazaar в курсе, но в данном случае речь про Mercurial.
88. ivanhoe , 16.11.2009 14:08
Pentero

Никто не мешает использовать UTF-8 в консоли винды.

89. Pentero , 03.12.2009 11:39
Вышел Mercurial 1.4.1 What’s new (http://mercurial.selenic.com/wiki/WhatsNew#A1.4.1_-_2009-12-01)
90. Pentero , 12.04.2010 12:14
Up. Вышел Mercurial 1.5.1

В GoogleGroups появилась русскоязычная группа (http://groups.google.ru/group/ru_hg) про Mercurial

91. dozen , 12.04.2010 18:16
Чисто совет тем, кто ставит плагин к Eclipse, чтобы не повторять мою ошибку. Гугль дает первую ссылку на плагин от Vectrace.

Он, однако устарел и упорно не ставится. Я убил час, пытаясь понять, что не так. Не так то, что надо ставить его развитие HGEclipse, которое надо брать тут:

Причем на странице Vectrace на него есть ссылка, но кто же дальше слов Download читает?

92. Yak , 23.07.2010 22:12
Джоэль Спольски призывает (http://hginit.com/00.html) лечить с помощью Mercurial повреждения мозга, вызванные использованием Subversion
93. Partisan , 23.07.2010 22:30
Джоэль пусть обломится. С SVN люди чаще переходят на Git, причём возможно и совместное использование SVN и Git. Однако Git для Windows при кратком ознакомлении мне показалась недоделанной, а plug-in Git для Eclipse — примитивным. Так что переходить рано, да и особой необходимости нпт. В общем, можно подождать пока всё доделают.
94. dozen , 23.07.2010 22:51
Partisan

С SVN люди чаще переходят на Git, причём возможно и совместное использование SVN и Git

Статистику в студию, плз. Я лично перешел как раз на M. Потому что git иначе как с красноглазыми после известного выступления Линуса не ассоциируется.

95. Yak , 23.07.2010 22:55
Partisan
С SVN люди чаще переходят на Git
Те, кто сидят на виндах — точно вряд ли.
96. ivanhoe , 23.07.2010 23:09
Partisan

У mercurial (как и у git) тоже есть svn-плагин, работает вполне нормально.

97. vertur , 24.07.2010 02:14
dozen
я перешел на гит, например.

цитата (Yak): Те, кто сидят на виндах — точно вряд ли.

Это все потому что некоторые черепахи просто безобразно написаны, плюс порт на вин безобразный. Что есть- то есть.

PS: Конечно толпа красноглазых все портит. Линус сказал — ох вах, бла-бла-бла, врочем апологеты стива джобса — не лучше.


Добавление от 24.07.2010 02:18:

zzf
нет -есть черепаший гуй — но он глючный настолько, что стыдно. Как будто пара студентов -первокуров взяли исходники черепахи и попытались присобачить к гиту.

«Родной» гуй — более-менее нормально. Но лучше всего — баш и консоль. («родной» — он конечно не родной, но спортирован с линукса).

Добавление от 24.07.2010 02:23:

Pentero
Каменты — только и только в utf-8. Забудте нафиг про всякие cp1251, dos866. Прошлый век уже прошел.

ЗЫ: Линус — конечно же гик, но. в чем то он в своих высказываниях прав, просто сужу по своему опыту.

ОПС — сорри, я про гит а не про меркуриал

98. Yak , 24.07.2010 11:31
ivanhoe
У mercurial (как и у git) тоже есть svn-плагин, работает вполне нормально.
У mercurial есть еще и git-плагин.

vertur
я перешел на гит, например.
Под виндой? Это замечательно, что перешли на гит, но всё-таки, оставаясь в рамках данного топика — почему не на mercurial?

Это все потому что некоторые черепахи просто безобразно написаны, плюс порт на вин безобразный. Что есть- то есть.
Дык, я это и имел в виду (правда, с заменой слова «всё» на фразу «в том числе»)

Mercurial обновление версии (контроль-версий, mercurial)

Есть репозиторий, созданный на старой версии Mercurial. Репозиторий используется локально, т.е. нет ситуации, когда возможны подключения клиентов разных версий. Теперь обновили Mercurial до версии 4.9.

Надо ли как то делать обновление самого репозитория, чтобы была возможность пользоваться функциями новой версии?

Ответы (1)

Надо ли как то делать обновление самого репозитория?

Заметки программистера

IT — это прекрасно!

Страницы

Контроль версий проекта в Mercurial

Разумеется, на этом преимущества использования Mercurial не заканчиваются, но лично мне достаточно и этих трех пунктов, чтобы однозначно сделать выбор в пользу Mercurial.

Правила нумерования версий системы

Стандартный рабочий цикл с VCS

Порядок использования системы управления версиями в каждом конкретном случае определяется техническими регламентами и правилами, принятыми в конкретной фирме или организации, разрабатывающей проект. Тем не менее, общие принципы правильного использования VCS немногочисленны и едины для любых разработок и систем управления версиями.

  1. Любые рабочие, тестовые или демонстрационные версии проекта собираются только из репозитория системы. «Персональные» сборки, включающие ещё не зафиксированные изменения, могут делать только разработчики для целей промежуточного тестирования. Таким образом, гарантируется, что репозиторий содержит всё необходимое для создания рабочей версии проекта.
  2. Текущая версия главной ветви всегда корректна. Не допускается фиксация в главной ветви неполных или не прошедших хотя бы предварительное тестирования изменений. В любой момент сборка проекта, проведённая из текущей версии, должна быть успешной.
  3. Любое значимое изменение должно оформляться как отдельная ветвь. Промежуточные результаты работы разработчика фиксируются в эту ветвь. После завершения работы над изменением ветвь объединяется со стволом. Исключения допускаются только для мелких изменений, работа над которыми ведётся одним разработчиком в течение не более чем одного рабочего дня.
  4. Версии проекта помечаются тэгами. Выделенная и помеченная тэгом версия более никогда не изменяется.

Требования к конвенции по работе с VCS

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

Diplom Consult.ru

Как мы сюда попали?

1.5. Почему следует остановить выбор на

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

• Прост в изучении и использовании

• Легко настраивается под конкретные нужды

Если вы обладаете опытом в использовании систем контроля версий, вам потребуется меньше пяти минут, чтобы начать работать с Mercurial. Если же вы новичок, процесс знакомства не должен занять больше десяти минут. Mercurial предоставляет единообразную и последовательную систему команд и функций, что позволяет руководствоваться небольшим набором общих правил вместо того, чтобы учить массу исключений.

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

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

Если вам не хватает базовой функциональности Mercurial, то её легко расширить. Mercurial хорошо подходит для задач скриптинга, его понятное устройство и реализация на языке Python позволяет легко добавлять новые возможности в виде расширений. Существует большое количество популярных и полезных расширений, охватывающих спектр задач от помощи в нахождении ошибок до улучшения производительности.

1.6. Сравнение Mercurial с другими системами контроля версий

Прежде чем вы продолжите чтение, вам следует уяснить, что этот раздел отражает мой опыт, интересы и (да, я осмелюсь сказать это) мои наклонности. Я использовал каждую из перечисленных ниже систем контроля версий в большинстве случаев в течение нескольких лет.

1.6.1. Subversion

Subversion — популярная система контроля версий, разработанная с целью заменить CVS. Subversion имеет централизованную клиент/серверную архитектуру.

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

Subversion до версии 1.5 не имел нормальной поддержки слияния. На момент написания книги возможность отслеживания слияний являлась относительно новой, с присущими сложностями и ошибками [http://svnbook.red-

В каждой операции, производительность которой я измерял, Mercurial обладает большей производительностью, чем Subversion. Скорость больше в 2-6 раз, когда речь идет о локальном репозитории Subversion 1.4.3 (самый быстрый метод доступа). При более реалистичном варианте использования — сетевой репозиторий, Subversion находится в существенно худшем положении. В силу того, что команды Subversion должны взаимодействовать с

Как мы сюда попали?

сервером и при этом Subversion не имеет полезных средств репликации, производительность сервера и пропускная способность сети становятся узкими местами даже для некрупных проектов.

Кроме того, Subversion требует дополнительное дисковое пространство для того, чтобы избежать сетевых запросов при выполнении некоторых операций: поиск модифицированных файлов ( status ) и отображение изменений ( diff ). В результате рабочая копия Subversion такого же размера (а то и больше) как репозиторий Mercurial и рабочий каталог вместе взятые, хотя репозиторий Mercurial содержит полную историю проекта.

Subversion имеет широкую поддержку инструментария сторонних производителей. В этом отношении у Mercurial сейчас существенное отставание. Хотя разрыв сокращается, и некоторые GUI-утилиты для Mercurial превосходят свои аналоги для Subversion. Как и Mercurial, Subversion располагает отличным руководством пользователя.

Из-за того, что Subversion не хранит историю изменений на клиенте, она хорошо подходит для управления проектами, содержащими большое количество двоичных файлов. Если вы внесете в несжимаемый десятимегабайтный файл 50 изменений, то дисковое пространство, использованное Subversion останется неизменным. Пространство, используемое любой из распределенных систем контроля версий, будет быстро увеличиваться пропорционально количеству изменений, потому что различия между правками большие.

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

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

Git — распределенная система контроля версий, которая была разработана для управления исходным кодом ядра Linux. Как и в случае с Mercurial, на начальный дизайн системы оказал влияние Monotone.

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

Что касается производительности — Git очень быстр. В некоторых случаях он быстрее, чем Mercurial (по крайней мере под Linux), а в других быстрее оказывается Mercurial. Однако под Windows как производительность, так и общий уровень поддержки, во время написания этой книги у Git гораздо хуже, чем у Mercurial.


В то время как репозиторий Mercurial не требует операций по техническому обслуживанию, репозиторий Git требует частых ручных «перепаковок» собственных метаданных. Если этого не делать, производительность начинает падать, наряду с увеличением объёма занимаемого дискового пространства. Дисковый массив сервера, содержащего несколько Git репозиториев, по отношению к которым не выполняется строгое правило частой «перепаковки», рано или поздно забивается под завязку, в результате чего процесс ежедневного резервного копирования легко может занимать более 24 часов. Только что «запакованный» репозиторий Git занимает немного меньше места, чем репозиторий Mercurial, но объём не перепакованного репозитория будет на несколько порядков больше.

Ядро Git написано на языке С. Многие команды Git реализованы в виде Shell скриптов или скриптов на языке Perl и уровень качества данных скриптов сильно разнится. Я встречал несколько установок, в которых скрипты тупо продолжали выполнение, несмотря на наличие фатальных ошибок.

Mercurial предоставляет возможность импорта истории версий из репозитория Git.

CVS, наверное, самая широко распространённая система контроля версий в мире. Благодаря почтенному возрасту, а также бардаку, царящему внутри, он очень слабо поддерживается уже много лет.

Как мы сюда попали?

CVS основан на централизованной, клиент-серверной архитектуре. Он не выполняет группировку файловых изменений в атомарные коммиты, тем самым позволяя людям легко «сломать билд»: один человек может успешно внести часть изменений в репозиторий, а затем оказаться заблокированным из-за необходимости выполнения слияния. Это приведёт к ситуации, когда остальные участники увидят только часть из тех изменений, которые они должны были увидеть. Данная особенность также влияет на то, как вы будете работать с историей изменений. Если вы хотите получить все изменения, которые один из членов команды внёс для решения определённой задачи, вам необходимо вручную исследовать описания и дату внесения изменений, произведённых для каждого затрагиваемого файла (если вы вообще знаете, какие файлы были затронуты).

CVS оперирует довольно запутанными понятиями веток и меток, которые я даже не буду пытаться описать в данной книге. Он не поддерживает переименование как файлов, так и папок, благодаря чему репозиторий может быть достаточно легко повреждён. Так как внутренние механизмы контроля целостности практически отсутствуют, зачастую даже невозможно точно утверждать, повреждён ли репозиторий, и если да, то каким образом. Таким образом я бы не стал рекомендовать CVS для использования в любом из существующих или новых проектов.

Mercurial предоставляет возможность импорта истории версий CVS. Тем не менее здесь есть несколько подводных камней, с которыми также сталкиваются любые другие инструменты иморта из CVS. Отсутствие атомарных изменений и версионирования иерархических данных файловой системы приводит к невозможности абсолютно точного реконструирования истории изменений CVS, поэтому в некоторых случаях используются допущения, а переименования обычно не отображаются. Так как множество задач по администрированию CVS должны выполняться вручную, что повышает риск ошибок, обычна ситуация, когда средство для импорта из CVS возвращает множество ошибок целостности репозитория (абсолютно нереальные даты изменения версий и файлы, которые остаются заблокированными на протяжении последнего десятка лет — это лишь пара из наименее интересных проблем, которые я могу вспомнить из собственного опыта).

Mercurial предоставляет возможность импорта истории версий из репозитория CVS.

1.6.4. Коммерческий инструментарий

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

Производительность Perforce вполне достаточна для небольших команд, но стремительно падает, если количество пользователей переваливает за пару дюжин. Умеренно большие установки Perforce требуют развёртывания проксисерверов для распределения нагрузки, генерируемой пользователями.

1.6.5. Выбор системы контроля версий

За исключением CVS, все инструменты, перечисленные выше, имеют уникальные свойства, которые делают их подходящими для определённых стилей ведения проектов. Не существует инструмента, который мог бы быть использован в любой ситуации.

Например, Subversion является хорошим выбором для работы с часто изменяющимися бинарными файлами, благодаря его централизованной архитектуре и поддержке блокировок на уровне файлов.

Лично меня в Mercurial привлекает простота, производительность и хорошая поддержка процесса слияния — этот превосходный набор служит мне уже несколько лет.

1.7. Переход с других систем контроля версий на

Mercurial поставляется с расширением под названием convert , которое пошагово импортирует историю изменений из некоторых систем контроля версий. Под словом «пошагово» я подразумеваю, что вы за один раз можете сконвертировать историю проекта до определенной даты, а позже запустить преобразование еще раз для получения изменений, произошедших после первичной конвертации.

Как мы сюда попали?

Поддерживаются преобразование из следующих систем контроля версий:

Кроме того, convert может экспортировать изменения из Mercurial в Subversion. Это позволяет использовать Subversion и Mercurial параллельно, без риска потери данных.

Команда convert проста в использовании. Просто укажите путь или URL исходного репозитория и имя целевого репозитория (необязательно), и она начнет работу. После первичного преобразования, запустите ту же самую команду для получения новых изменений.

1.8. Краткая история контроля версий

Самая известная из старых утилит контроля версий — SCCS (Source Code Control System, система контроля исходного кода), которую написал Марк Рочкайнд (Marc Rochkind) из Bell Labs, в начале 70-х. SCCS оперировала отдельными файлами и требовала, чтобы каждый человек, работающий над проектом, имел доступ к общему рабочему пространству, существовавшему в единственном экземпляре. Только один человек мог одновременно редактировать файл в один момент времени; конфликты доступа к файлам разрешались блокировками. Обычной ситуацией было забывание снятия блокировки после редактирования, что запрещало доступ к файлу другим людям без помощи администратора.

Вальтер Тичи (Walter Tichy) разработал свободную альтернативу SCCS в начале 1980-х; он назвал свою программу RCS (Revision Control System, система контроля ревизий). Подобно SCCS, RCS требовала от разработчиков как работы в едином разделяемом рабочем пространстве, так и блокировки файлов для предотвращения одновременного изменения файлов разными людьми.

Позднее, в 1980-х же годах, Дик Грюн (Dick Grune) использовал RCS как основу для набора shellскриптов, изначально названных cmt, а позднее переименованных в CVS (Concurrent Versions System, система одновременных версий). Крупное нововведение CVS заключалось в том, что она позволяла разработчикам работать одновременно и, в некоторой степени, независимо в их личных рабочих пространствах. Этими-то пространствами и предотвратились постоянные наступания разработчиков друг другу на пятки, которое было обычным делом в SCCS и RCS. Каждый разработчик имел копию каждого файла проекта, разработчики могли модифицировать свои копии независимо. Им приходилось объединять собственные правки только перед отсылкою изменений в центральное хранилище.

Брайан Берлинер (Brian Berliner) взял первоначальные скрипты Грюна и переписал их на Си, выпустив в 1989 году код, который впоследствии развился в современную версию CVS. CVS в дальнейшем приобрела возможность работать по сети, обретя клиент-серверную архитектуру. Архитектура CVS является централизованной: только на сервере есть копия истории проекта. Клиентские рабочие копии содержали только экземпляры файлов последней версии и небольшие метаданные для определения местонахождения сервера. Система CVS достигла небывалого успеха: вероятно, она является самой широко используемой системой контроля версий в мире.

В начале 1990-х годов Sun Microsystems разработала раннюю распределённую систему контроля версий, называвшуюся TeamWare. Каждая рабочая копия TeamWare содержала полную копию истории изменений проекта. Понятие центрального репозитория в TeamWare отсутствовало как таковое. (Подобно CVS, использовавшей RCS для хранения истории, TeamWare использовала SCCS.)

Шли 1990-ые, росла осведомлённость о нескольких проблемах CVS. Система записывает одновременные изменения нескольких файлов раздельно, а не группирует их в одну логически атомарную операцию. Способ управления файловой иерархией не очень хорош: нетрудно устроить в репозитории беспорядок, переименовывая файлы и каталоги. Более того, исходные коды CVS непросто понимать и поддерживать, что сделало практически непреодолимым «болевой порог» исправления этих архитектурных проблем.

Как мы сюда попали?

В 2001 году Джим Бланди (Jim Blandy) и Карл Фогель (Karl Fogel) — два разработчика, прежде работавшие над CVS

— начали проект по её замене таким средством, которое имело бы архитектуру получше и код почище. Результат

— Subversion — не отошёл от централизованной клиент-серверной модели CVS, но добавил атомарные коммиты нескольких файлов, лучшее управление пространствами имён и другие возможности, которые сделали Subversion более удобным средством работы, нежели CVS. Со времени выхода первой версии Subversion быстро обретал популярность.

Более или менее одновременно, Грейдон Хоар (Graydon Hoare) начал работать над амбициозной системой контроля версий, которую назвал Monotone. Эта система не только устраняет множество проблем внутреннего устройства CVS и имеет распределённую архитектуру, но и идёт далее нескольких прежних (и последующих) систем контроля версий в некоторых своих нововведениях. Monotone использует криптографические хеши в качестве идентификаторов и имеет неотъемлемое представление о «доверии» коду из различных источников.

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

Git для начинающих. Часть 1. Что такое системы контроля версий?

Система контроля версий (Version Control System, VCS) представляет собой программное обеспечение, которое позволяет отслеживать изменения в документах, при необходимости производить их откат, определять, кто и когда внес исправления и т.п. В статье рассмотрены виды VCS, принципы их работы, а также приведены примеры программных продуктов.

Что такое система контроля версий?

Наверное, всем знакома ситуация, когда при работе над проектом, возникает необходимость внести изменения, но при этом нужно сохранить работоспособный вариант, в таком случае, как правило, создается новая папка, название которой скорее всего будет “Новая папка” с дополнением в виде даты или небольшой пометки, в нее копируется рабочая версия проекта и уже с ним производится работа. Со временем количество таких папок может значительно возрасти, что создает трудности в вопросе отката на предыдущие версии, отслеживании изменений и т.п. Эта ситуация значительно ухудшается, когда над проектом работает несколько человек.

Для решения таких проблем как раз и используется система контроля версий, она позволяет комфортно работать над проектом как индивидуально, так в коллективе. VCS отслеживает изменения в файлах, предоставляет возможности для создания новых и слияние существующих ветвей проекта, производит контроль доступа пользователей к проекту, позволяет откатывать исправления и определять кто, когда и какие изменения вносил в проект. Основным понятием VCS является репозиторий (repository) – специальное хранилище файлов и папок проекта, изменения в которых отслеживаются. В распоряжении разработчика имеется так называемая “рабочая копия” (working copy) проекта, с которой он непосредственно работает. Рабочую копию необходимо периодически синхронизировать с репозиторием, эта операция предполагает отправку в него изменений, которые пользователь внес в свою рабочую копию (такая операция называется commit) и актуализацию рабочей копии, в процессе которой к пользователю загружается последняя версия из репозитория (этот процесс носит название update).

Централизованные и распределенные системы контроля версий

Системы контроля версий можно разделить на две группы: распределенные и централизованные.

Централизованные системы контроля версий

Централизованные системы контроля версий представляют собой приложения типа клиент-сервер, когда репозиторий проекта существует в единственном экземпляре и хранится на сервере. Доступ к нему осуществлялся через специальное клиентское приложение. В качестве примеров таких программных продуктов можно привести CVS, Subversion.

CVS (Concurrent Versions System, Система одновременных версий) одна из первых систем получивших широкое распространение среди разработчиков, она возникла в конце 80-х годов прошлого века. В настоящее время этот продукт не развивается, это в первую очередь связано с рядом ключевых недостатков, таких как невозможность переименования файлов, неэффективное их хранение, практически полное отсутствие контроля целостности.

Subversion (SVN) – система контроля версий, созданная на замену CVS. SVN была разработана в 2004 году и до сих пор используется. Несмотря на многие преимущества по сравнению с CVS у SVN все-таки есть недостатки, такие как проблемы с переименованием, невозможность удаления данных из хранилища, проблемы в операции слияния ветвей и т.д. В целом SVN был (и остается) значительном шагом вперед по сравнению с CVS.

Распределенные системы контроля версий

Распределенные системы контроля версий (Distributed Version Control System, DVCS) позволяют хранить репозиторий (его копию) у каждого разработчика, работающего с данной системой. При этом можно выделить центральный репозиторий (условно), в который будут отправляться изменения из локальных и, с ним же эти локальные репозитории будут синхронизироваться. При работе с такой системой, пользователи периодически синхронизируют свои локальные репозитории с центральным и работают непосредственно со своей локальной копией. После внесения достаточного количества изменений в локальную копию они (изменения) отправляются на сервер. При этом сервер, чаще всего, выбирается условно, т.к. в большинстве DVCS нет такого понятия как “выделенный сервер с центральным репозиторием”.

Большое преимущество такого подхода заключается в автономии разработчика при работе над проектом, гибкости общей системы и повышение надежности, благодаря тому, что каждый разработчик имеет локальную копию центрального репозитория. Две наиболее известные DVCS – это Git и Mercurial.

Начнем с Mercurial, эта система представляет собой свободную DVCS, которая построена таким образом, что в ней отсутствует понятие центрального репозитория, для работы с этой VCS используется (как правило) консольная утилита hg. Mercurial обладает всеми возможностями системы контроля версий, такими как ветвление, слияние, синхронизация с другими репозиториями. Данный проект используют и поддерживают большое количество крупных разработчиков, среди них Mozilla, OpenOffice, OpenJDK и многие другие. Сам продукт написан на языке Python и доступен на большинстве современных операционных систем (Windows, Mac OS, Linux), также существует значительное количество утилит с графическим интерфейсом для работы с Mercurial. Основным конкурентом Mercurial на рынке распределенных систем контроля версий является Git, который, на сегодняшний день, выиграл гонку за лидерство.

Git – распределенная система контроля версий, разработанная Линусом Торвальдсем для работы над ядром операционной системы Linux. Среди крупных проектов, в рамках которых используется git, можно выделить ядро Linux, Qt, Android. Git свободен и распространяется под лицензией GNU GPL 2 и, также как Mercurial, доступен практически на всех операционных системах. По своим базовым возможностям git схож с Mercurial (и другими DVCS), но благодаря ряду достоинств (высокая скорость работы, возможность интеграции с другими VCS, удобный интерфейс) и очень активному сообществу, сформировавшемуся вокруг этой системы, git вышел в лидеры рынка распределенных систем контроля версий. Необходимо отметить, что несмотря на большую популярность таких систем как git, крупные корпорации, подобные Google, используют свои VCS.

Это была вводная лекция по системам контроля версий. В дальнейшем, все изложение будет касаться только git.

Если вам больше нравится учиться по видео-лекциям, то рекомендуем классный курс по git от GeekBrains , перейдите по ссылке и найдите в разделе “Курсы” курс “Git. Быстрый старт” . Он бесплатный, нужно только зарегистрироваться на сайте. Рекомендуем повнимательнее посмотреть на этот ресурс, на нем ещё очень много чего интересного!

Tortoise HG — клиент для Mercurial


Здравствуйте, уважаемые читатели блога LifeExample, за последний месяц мой проект MOGUTA.CMS приобрел более-менее устоявшийся состав команды, и мы вместе принялись дописывать продукт, разработанный в цикле статей о создании интернет магазина.

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

Эта задача легко разрешима при использовании одной из распространенных систем контроля версий (VCS — Version Control System), таких как SVN, GIT, Mercurial, Bazaar.

Однажды на блоге я уже писал о системе контроля версий — SVN, в статье «Настройка SVN», и сначала при организации, совместных, процессов разработки MOGUTA.CMS, мы даже стали использовать именно SVN, но впоследствии окончательный выбор пал на Mercurial.

Этому решению способствовало несколько фактов:

  1. Mercurialболее производителен в отличии от SVN, за счет своей концепции в основе которой лежит использование распределенных хранилищ.
  2. Mercurialочень прост в понимании использовании.

Учитывая то, что наша команда состоит в основном из людей, не работавших с системами контроля версий, мы приняли решение использовать подкупившего своей простотой Mercurial’a.

Для полноценного тестирования примеров из этой статьи вы можете воспользоваться сервисом https://www.assembla.com, предоставляющим бесплатные сервера для Mercurial и других VCS.

После регистрации на этом сервисе и проведенных настроек для использования Mercurial, мы получим ссылку для доступа к главному репозиторию на удаленном сервере, примерно такого вида: https://hg.assembla.com/moguta

Имея в наличии эту ссылку, мы можем приступить к использованию хранилища с помощью клиентской программы Tortoise hg. Скачать и установить ее себе на компьютер можно с официального сайта http://tortoisehg.bitbucket.org

Как использовать Tortoise hg

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

    После установки Tortoise hg, в контекстное меню проводника добавятся два пункта: «Hg WorkBench» и «TourtoiseHg«.

Если вы пользуетесь другим сервером, тогда логин и пароль должен выдать администратор.

  • После успешного клонирования, можно начинать работу с проектом , изменяя, добавляя и удаляя принадлежащие ему файлы.
  • После того как будет внесён, какой-то набор правок, мы можем записать его в узел дерева изменений проекта. Тем самым увековечив эту версию в памяти Mercuriala.

    Чтобы записать сделанные изменения перейдем в интерфейс программы Tortoise Hg, кликнув по пункту «Hg WorkBench» из контекстного меню папки с проектом.

    Самое важное в работе с VCS, понимать, как работает система веток. Если взглянуть на граф ревизий, то можно увидеть множество переплетающихся между собой версий проекта

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

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

    Коммит – по-русски говоря это сохранение текущего набора изменений в новую ревизию (версию проекта).

    Как создать ветку в Tortoise HG

    Мы остановились на том, что создали новый файл в проекте и открыли интерфейс управления Tortoise HG. Посмотрите на приведенную выше иллюстрацию.

    Пронумерованные поля, выделенные, красным контуром предназначены для следующих действий:

    • 1: показывает, в какой ветке мы сейчас находимся, об этом говорит, помещенное между двух звезд описание: «Рабочий каталог«.
    • 2: также показывает название текущей ветки, а кроме этого является кнопкой для создания новой. Нажав на нее, Tortoise HG предложит создать именованную ветку. Сделаем новое ответвление проекта.

    Как слить ветки в Tortoise HG

    С внесением правок и созданием новой ветки вроде разобрались.

    Хочу обратить внимание: при следующем коммите, не надо создавать новую ветку, делайте все тоже, что описано в предыдущем разделе, но миновав пункт с созданием именованной ветки.

    Делать много коммитов в одной ветке полезно, для того чтобы в нужный момент откатиться до предыдущей версии и посмотреть как работала система ранее. Но злоупотреблять коммитами я не рекомендую, делайте их только тогда когда считаете, что закончили какую-то часть работы. Обычно хватает, делать коммит в конце и/или начале рабочего дня.

    Как обновляться до предыдущей ревизии

    Tortoise HG позволяет двумя простыми кликами мыши, обновиться до любого узла имеющегося в графе ревизий. Кто-бы ни являлся автором коммита, мы всегда можем, нажав правой кнопкой мыши на узел графа, выбрать пункт – «Обновить…» и получить желаемую версию проекта.

    После обновления, внешний вид графа несколько изменится, но на его структуру это никак не повлияет, просто Tortoise HG отобразит его более удобным для восприятия способом. С обновлением до какой либо ревизии поменяются данные в полях 1 и 2, приведенных на иллюстрации с разметкой.

    Вот так будет выглядеть в нашем примере граф после обновления:

    Как слить ветки проекта

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

    Кстати, я упустил момент, и не сказал, что дефолтная ветка – это ветка, которая содержит текущую стабильную версию проекта, т.е. сливаться с ней можно только тогда, когда все правки отлажены и протестированы.

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

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

    А затем кликом правой кнопкой мыши, по узлу графа, с нашим коммитом (ревизия 69), выберем меню «Слить с локальной».

    После клика по пункту, будут появляться диалоговые окна, во всех них, жмем «Далее».
    В результате получим такую картину графа, и обновленную дефолтную ветвь проекта.

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

    Как узнать, что дефолтная ветка обновилась

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

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

    Чтобы затянуть изменения, если таковые имеются, в панели управления Tortoise HG, есть советующая иконка, которая называется «Затянуть входящие изменения с выбранного URL».

    Вот что я получил, нажав на кнопку затянуть изменения с сервера:

    Оказывается, пока я делал тестовые изменения для демонстрации работы, кто-то из команды внес свои правки и закоммитил данные. Но не просто закоммитил, а отправил их на сервер, для общего обозревания и использования.

    Я еще не упоминал об этом, и вот время пришло. Все действия которые мы делали, производились над нашей локальной рабочей копией хранилища. Вот она, та самая удобность, которая есть у Mercurial и нет у SVN, все коммиты которые мы делали, сохранялись только на нашем компьютере, и не мешали другим.

    Как применить свои изменения на центральном сервере

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

    Делается это нажатием на кнопку «Протолкнуть исходящие изменения на выбранный URL»

    Отправив свои данные на сервер, мы даем возможность остальным участникам проекта, затянуть их к себе на рабочую копию, и использовать в своих целях и целях всего проекта.


    Проблема с отправкой на сервер

    К сожалению, не все так гладко как описано выше, в реальности при отправке на сервер своих правок, часто можно получить похожую ошибку:

    searching for changes
    abort: push creates new remote head 3a37da9642d5!
    (you should pull and merge or use push -f to force)

    Означает она, то что, после того как вы затянули изменения (а может и не затянули, хотя обязаны) в графе ревизий появилось две головы одной и той же ветки. Такое может случиться когда два разработчика работают в одной ветке, и периодически делают коммиты.

    В этой ситуации второй разработчик, пока мы делали правки, внес свои изменения, и теперь нам надо с ними считаться.

    Другими словами, нам надо сделать из двух версий одной и той же ветки лишь одну.

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

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

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

    В теории это все, сложно, но на практике значительно легче чем кажется. Поэтому не стоит бояться конфликтов, все они решаемы.

    Tortoise HG все время требует логин и пароль

    Если вы опробовали в действии Tortoise HG, то наверняка заметили назойливую проверку каждого действия, запросом логина и пароля. Дабы не утруждать Tortoise HG, запрашивать у нас эти данные, нужно сделать одну настройку.

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

    То что должно быть:

    [paths]
    default = https://ВашНик:ВашПароль@hg.assembla.com/moguta

    Сохраним файл, и перезапустим Workbench HG.
    После этих действий, запрос пароля перестанет докучать нам.

    Эта статья по обзору Tortoise HG получилась очень насыщенной информацией и иллюстрациями. Надеюсь, она поможет разобраться с основными аспектами работы с Mercurial.

    Очередной блог фрилансера

    коротко и полезно о веб-разработке

    Система контроля версий Mercurial tortoiseHg

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

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

    Для чего нужна система контроля версий?

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

    1. Во-первых для того чтобы сберечь собственные нервы, потому что если вдруг что-то пойдет не так, или вы случайно испортите какие-либо файлы, всегда была возможность вернуться на предыдущий этап.
    2. Во-вторых чтобы сэкономить собственное время, просматривая какие именно изменения вносились в ваш проект другими людьми, в результате которых он перестал нормально работать
    3. В третьих чтобы иметь возможность вести одновременную работу над будущей системой, а затем быстро и безболезненно объединять все фрагменты в один проект.

    Список можно еще немного продолжить, но я думаю не стоит, потому что выдвинутых аргументов должно быть вполне достаточно. Системы контроля версий бывают разные, в частности мне известны SVN и Mercurial. У каждой системы есть свои поклонники, мне пока не доводилось работать с SVN, поэтому мы сегодня поговорим о Mercurial, а точнее о графической оболочке к ней под названием TortoiseHg.

    С чего начать?

    Начать нужно с непосредственной установки TortoiseHg, скачать последнюю версию можно отсюда. Процесс установки я думаю ни у кого сложностей не вызовет, отдельно Меркуриал устанавливать не нужно, посколько он интегрирован в Tortoise. Вот и все, теперь у вас есть своя система контроля версий, и все ее широкие возможности, доступные всего лишь по правому клику мыши.

    Создание репозитория

    Правила работы разберем на примере. Допустим у нас есть обычный html-файл, хрянящийся в папке works. Для того чтобы следить за историей его изменений, нам нужно создать репозиторий, где эти изменения будут хранится. Для этого следует нажать правой кнопкой мыши на папке works, вызвав контекстное меню, и выполнить команду TortoiseHg — «Create a repository here».

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

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

    Для того чтобы создать первую, начальную версию нашего проекта, снова вызовем контекстное меню на папке works и выполним команду TortoiseHg — «Commit».

    Следует заметить, что команда Commit, становится доступной из контекстного меню, только после создания репозитория. На экране должно появится окно следующего вида:

    Здесь мы можем отметить все или конкретные файлы, по которым будем отслеживать изменения. И конечно же нужно ввести имя для сохраняемой версии. Поскольку мы отмечаем первую версию проекта, то так ее и назовем. Затем нажимаем кнопку Commit, и все наша первая версия проекта сохранена.

    Хорошенько запомните комманду Commit (одно из значений в английском — фиксировать), поскольку она является основной при работе с Mercurial. То есть после того как вы внесли какие-либо серьезные изменения, или просто сделали очередной этап работы, зафиксируйте изменения, в виде следующей ветки проекта.

    Внесение изменений

    Теперь внесем несколько незначительных изменений в наш файл. Прежде чем мы зафиксируем следующий этап работы над нашим проектом, мы можем проследить какие именно изменения были внесены, после сохранения последней версии. Для этого, опять же из контекстного меню, нужно выполнить команду: TortoiseHg — «VisualDiff». На экране отобразится следующее окошко:

    Окно разделено на две области, левая область (как нетрудно догадаться) отображает прежний вариант файла, правая то что было изменено. Здесь можно внимательно проанализировать внесенные изменения, и если нужно отменить их, с помощью команды «Undo Changes», доступной все по тому же контекстному меню. Здесь хорошо можно видеть, что мы добавили заголовок H1.

    Если же все изменения вас устраивают, то можно смело выполнять команду «Commit», и сохранять вторую версию нашего проекта. После этого можно посмотреть историю версий проекта, по команде TortoiseHg — «View Changelog».

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

    И это еще не все

    У tortoiseHg, есть множество других возможностей, таких как объединение нескольких веток разработки в одну, отслеживание состояния файлов, возможность создавать клон репозитория на флешке, для работы на разных компьютерах, синхронизация репозиториев и др.

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

    Рассказать друзьям

    Понравилась статья? Лучший способ сказать спасибо — поделиться ссылкой в социальных сетях:

    Выпуск распределённой системы управления версиями Mercurial 4.8 05.11.2020 10:18

    Доступен релиз распределённой системы управления версиями Mercurial 4.8. Код Mercurial написан на языке Python (требующие высокой производительности части оформлены в виде модулей на Си) и распространяется под лицензией GPLv2+. Среди проектов, использующих Mercurial, можно выделить следующие: Mozilla, OpenOffice.org, OpenSolaris, NetBeans, OpenJDK, Nginx, Xine и W3C.

    • Стабилизирована реализация шаблонов форматирования, которые можно применять для настройки формата вывода любых команд, в том числе для применения JSON и XML для вывода;
    • Реализовано расширение «closehead» для закрытия произвольных веток без выполнения операции checkout;
    • Добавлена новая настройка commands.resolve.mark-check для вывода предупреждения или ошибки при выполнении операции »—mark» при наличии конфликтующих файлов;
    • Добавлена новая настройка commands.resolve.confirm для подтверждения действий, выполняемых без указания имени файла;
    • В команду rebase добавлен флаг »—stop» для остановки прерванных операций без отбрасывания уже перенесённых изменений;
    • Предложено экспериментальное расширение absorb для «поглощения» рабочих изменений соответствующими наборами изменений;
    • Добавлено экспериментальное расширение fastannotate для ускорения операций аннотирования с использованием предварительно сформированного кэша. Расширение также предоставляет дополнительные опции, такие как »—deleted»;
    • В набор hgext добавлено расширение phabricator;
    • В файл конфигурации добавлена настройка http.timeout для определения таймаута;
    • Обеспечена автоматическая загрузка расширений для работы с текущим хранилищем (например, lfs);
    • Расширены правила автодополнения ввода команд hg для zsh;
    • Проведены оптимизации производительности.
    • Быстродействие:
      • Высокая производительность работы с хранилищем, не зависящая от числа элементом в нём (O (1) revlog);
      • Компактное хранение данных в проиндексированном и сжатом виде;
      • Оптимизирован для эффективной работы с данными на жёстком диске;
      • Все изменения и файлы в репозитории дополнительно проиндексированы;
      • Для копирования данных по сети используется HTTPS и SSH, данные передаются в сжатом виде.
    • Масштабирование
      • Распределённая модель разработки позволяет участвовать в проекте неограниченному числу разработчиков;
      • Допускается произвольное слияние отдельных децентрализованных репозиториев, поддерживаемых отдельными разработчиками;
      • Объём репозитория, число файлов и зафиксированных изменений не отражается отрицательно на производительности;
      • При работе нет необходимости ждать освобождения блокировки.
    • Надёжность.
      • Для контроля целостности данных в репозитории используется SHA1 (запланирован переход на SHA256);
      • Хранилище реализовано в журнальном виде — данные не замещаются, а добавляются. Ведётся журнал транзакций;
      • Быстрый алгоритм проверки целостности репозитория;
      • Встроенные средства резервного копирования и проверки целостности;
    • Удобство использования.
      • Привычный CVS-подобный набор команд;
      • Наличие встроенной системы подсказки;
      • Интегрированный Web-интерфейс;
      • Большой выбор GUI-интерфейсов.
    • Лёгкость внедрения:
      • Поддержка платформ UNIX, macOS и Windows;
      • Средства, упрощающие миграцию с других систем управления исходными текстами;
      • Поддержка нескольких моделей организации репозитория: централизованная cvs-подобная, децентрализованная иерархическая и распределённая полуиерархическая;
      • Поддержка внешних обработчиков и дополнений.
    Мастер Йода рекомендует:  Разработчики Steam анонсировали прекращение поддержки Windows XP и Vista
    Добавить комментарий