LINUX.ORG.RU

Mercurial 3.8

 


0

7

Вышла очередная версия Mercurial — распределённой системы управления версиями, написанной на Python.

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

fsmonitor

Добавлено расширение fsmonitor (ранее известное как «hgwatchman»), разработанное компанией Facebook. Такие операции, как hg status, hg diff, hg commit должны знать о том, какие файлы в репозитории были изменены. В нормальной ситуации это требует обращения к каждому файлу для проверки изменений. fsmonitor использует сервис watchman, чтобы получать уведомления об изменениях. watchman в свою очередь, использует специфичные для платформы API, такие как inotify или FSevents, чтобы получать уведомления от операционной системы всякий раз, когда файл в хранилище изменился. Используя fsmonitor, команды hg status, hg diff и другие, должны проверять только те файлы, которые на самом деле изменились, вместо того, чтобы обходить всё хранилище.

automv

Другим важным изменением является введение экспериментального расширения automv. Обычно, люди перемещают файлы в своих репозиториях используя команды hg mv или hg cp. Несмотря на это, вполне легко забыть об этих командах и использовать обычное перемещение, особенно при использовании IDE. Расширение automv пытается определить похожие файлы при коммите и отмечает их как перемещённые/скопированные.

chg

Новый интегрированный chg клиент предоставляет альтернативный способ запуска Mercurial команд. Причиной низкой производительности Mercurial с точки зрения скорости команд является то, что он написан на Python. Это обычно не ограничивающий фактор, но запуск интерпретатора добавляет некоторые накладные расходы. Chg решает эту проблему, используя клиент, реализованный на C, и сервер на Python. Вместо того, чтобы запускать интерпретатор Python для каждой команды, вызов chg запускает простое C-приложение, которое общается с сервером команд.

>>> Примечания к выпуску

>>> Подробности

★★★★★

Проверено: leave ()
Последнее исправление: Psych218 (всего исправлений: 3)

Ответ на: комментарий от tailgunner

Во-первых, нет

Это так кажется, пока в глубины вникать не начинаешь. «Нафиг эти инструкции, quick guide на полстраницы а дальше как-то само пойдет...»

во-вторых, VCS - не сложная вещь.

VCS - нет. DVCS - да. Ну если тебе нужно что-то сложнее add/commit/push в один и тот же remote. Если нет - тебе с CVS подойдет :-)

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Pinkbyte

VCS - нет. DVCS - да

Ты не поверишь, но DVCS мало отличается от VCS на пользовательском уровне (см. историю опенсорсных DVCS - Arch, SVK). То, что DVCS _кажется_ намного более сложной - это по большей части заслуга Git.

Ну если тебе нужно что-то сложнее add/commit/push в один и тот же remote. Если нет - тебе с CVS подойдет :-)

Кхм. Вообще-то DVCS по сравнению с VCS добавляет 2 операции - push и pull. Остальное - детская радость Линуса и К «о, смотрите, как мы можем!». Хорошо хоть octopus merge в народ не пошло.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

А по факту получилось коммчно - hg созданный для разработчиков, чтобы они могли легко его расширять, оказался невостребованным. Зато дубовый git, который никак под себя не подстроишь пользуется популярностью благодаря авторитету Линуса.

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

То есть наборы их используешь на свой страх и риск. Есть только один вариант - не больше одного расширения. А в таком варианте hg сильно проигрывает git.

x86_64 ★★★
()
Ответ на: комментарий от x86_64

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

Примеры, пожалуйста.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

То, что DVCS _кажется_ намного более сложной - это по большей части заслуга Git.

Тем не менее я не осилил mercurial, но осилил git. Мне как раз mercurial показался более сложным и неочевидным.

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

во-вторых, VCS - не сложная вещь.

VCS - нет. git - да

anonymous
()
Ответ на: комментарий от Pinkbyte

Тем не менее я не осилил mercurial, но осилил git

А я не осилил Perforce - нафига он мне %)

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

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

Pinkbyte ★★★★★
()

Тормозит небось?

IPR ★★★★★
()
Ответ на: комментарий от anonymous

Если в firefox было бы нужно поставить расширения, чтобы смотреть HTML, еще одно чтобы рендерить CSS и еще одно - чтобы заработал Javascript - да, наверное я бы немного напрягся.

Pinkbyte ★★★★★
()
Ответ на: комментарий от DELIRIUM

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

я мог бы объяснить на пальцах, но местные фанатики начнут придираться к словам. поэтому лучше обратись к документации :)

waker ★★★★★
()
Ответ на: комментарий от tailgunner

То, что DVCS _кажется_ намного более сложной - это по большей части заслуга Git.

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

mashina ★★★★★
()
Ответ на: комментарий от littlechris

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

ты сам-то пробовал этот largefiles? лучше уж сразу perforce.

waker ★★★★★
()
Ответ на: комментарий от Pinkbyte

Интуитивно понятный интерфейс есть только один - это сиська.

Ы! И к нему идут талмуды. Посмотри на книги для кормящих матерей. Там столько тонкостей.... :)

x86_64 ★★★
()
Ответ на: комментарий от mashina

Git популяризовал DVCS

Возможно. Я не следил за опросами популярности.

всегда находится прослойка дилетантов которые где-то что-то не поняли. Воздыхатели топика как раз таковыми и являются.

Ути-пути, деточка, ты слишком много кушаешь.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Примеры, пожалуйста.

Уже писал и давно. Это личной опыт. Деталей не помню. Но результатом была потеря репозитория.

И опыт этот обоснован. Механизм расширеня у python слишком гибкий. Разработчики одних расширений не сильно интересуются другими. Одни меняют, другие не учитывают возможности таких изменений. Результат - я на git'е.

x86_64 ★★★
()
Ответ на: комментарий от tailgunner

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

x86_64 ★★★
()
Ответ на: комментарий от x86_64

В этом плане с гитом такого не наворотишь. Команды верхнего уровня работают поверих команд низкого.

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

tailgunner ★★★★★
()
Ответ на: комментарий от Dendy

Я правильно понял в плане концепции, что hg bookmark это аналог git branch

да

а hg branch это аналог git worktree?

нет. git worktree это такой куцый и не-совсем-рабочий клон hg share extension (см. скрипт hg-new-workdir в bitbucket.org/facebook/hg-experimental). у hg бранчей нет прямого аналога в гите.

val-amart ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

Проблемы в том что в hg одно расширение с некоторой долей вероятности помешает другому из-за самой системы расширений.

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

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

x86_64 ★★★
()
Ответ на: комментарий от tailgunner

Это теоретизирование относится к Git ровно так же, как к Mercurial.

Когда я наткнулся на проблему и пытался разобраться смотрел как расширения встраиваются в hg. Это не жесть. Это АБСОЛЮТНАЯ ЖЕСТЬ. В одном из них, как минимум, при установке расширения просто подменялась работа базового метода, который, естественно, используют все кому не лень.

В git утилиты верхнего уровня не меняют работу утилит базового.

x86_64 ★★★
()
Ответ на: комментарий от r_asian

Тем кто использовал только git, но не hg - приходится объяснять, что `бранчи - это сложно`, а то они не в курсе. :-)

anonymous
()
Ответ на: комментарий от x86_64

Это не жесть. Это АБСОЛЮТНАЯ ЖЕСТЬ. [...] просто подменялась работа базового метода, который, естественно, используют все кому не лень.

Риальне жесть. На ней, правда, половина ООП строится, но ЭТО ЖЕСТЬ!!!11

tailgunner ★★★★★
()
Ответ на: комментарий от littlechris

hg-git.github.io

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

selivan ★★★
()
Ответ на: комментарий от Vudod

Windows --- это пользователи, Windows --- это драйверы и устройства, Windows --- это коммерческая разработка. Хочешь зарабатывать? Хочешь, чтобы твою программу использовал кто-то ещё? Хочешь стать известным в широких кругах? Пиши для Windows.

Ничего не напоминает?

Да, и определённые классы программ (бух. учёт, офис, CAD, ...) без поддержки Windows смысла не имеют - пользоваться будут 3.5 анонимуса. Но если софт можно писать крос-платформенный, то система контроля версий в проекте может быть одна, и выбирать призодится ту, которая более популярна у сообщества.

Например: я изредка посылаю PR проектам на гитхаб, если нашёл фигню и вижу, как исправить. А если проект хостится на каком-нибудь launchpad с bazaar - я PR не пришлю, потому что мне учить ещё одну VCS и разбираться как оно работает - лень. Максимум баг отрепорчу.

selivan ★★★
()
Ответ на: комментарий от littlechris

Про то, что история скопированного файла начинается с момента копирования, я вообще молчу.

git log --follow

// мимокрокодил

arcanis ★★★★
()
Ответ на: комментарий от littlechris

В Unity Technologies используют минимум с 2013, тоже работает.

^^^ я как раз там и работаю.

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

upd: ах да, забыл уточнить: оно _с трудом_ кое-как, со скрипом (криво), с постоянным твиканьем, и с ручным вмешательством нескольких разработчиков hg, справляется с нашим очень маленьким репозиторием, порядка 25-30 гигов.

на том, что описал iZen, оно бы померло сразу.

и я знаю о чем говорю, т.к. непосредственно работаю в команде с этими ребятами, и вижу их страдания :)

waker ★★★★★
()
Последнее исправление: waker (всего исправлений: 1)
Ответ на: комментарий от littlechris

и еще одно уточнение.

вот это был исходный вопрос:

Интересно, Mercurial или что-то подобное на его идеях потянет _распределённый_ документооборот

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

ничего _распределенного_ в нем замечено не было.

waker ★★★★★
()
Ответ на: комментарий от tailgunner

Риальне жесть. На ней, правда, половина ООП строится, но ЭТО ЖЕСТЬ!!!11

разве что в среде питонщиков и жаваскриптщиков, да и то не факт.

waker ★★★★★
()
Последнее исправление: waker (всего исправлений: 1)
Ответ на: комментарий от littlechris

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

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

arcanis ★★★★
()
Ответ на: комментарий от littlechris

Таки сломали к 2016, или это вы что-то недоговариваете?

??? что именно?

на моей памяти, largefiles без центрального сервера никогда не работало. я им пользуюсь с 2013 года (столько же, сколько пользуюсь hg вообще).

waker ★★★★★
()
Ответ на: комментарий от waker

Всё ООП строится на замене одних реализаций другими. Делается это через virtual, тотальный динамический диспатч, через замену указателей функций, как в твоем любимом Си, или через тупой манкипатчинг - неважно.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

через замену указателей функций, как в твоем любимом Си

это не является общепринятой практикой, но используется как хак, изредка.

Делается это через virtual

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

waker ★★★★★
()
Последнее исправление: waker (всего исправлений: 1)
Ответ на: комментарий от littlechris

Покажите, как именно оно «не работает без центрального сервера».

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

(но это не единственное проявление, просто сейчас сходу не вспомню)

например, прямо сейчас выключил wifi, и попытался переключить ветку, получил вот это:

abort: error: nodename nor servname provided, or not known

waker ★★★★★
()
Последнее исправление: waker (всего исправлений: 1)
Ответ на: комментарий от littlechris

Так… а покажите пжлст вывод hg showconfig largefiles.usercache

А вот это уже подло.

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.